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INTRODUCTION 



This manual provides a high-level overview of the Physical Input/Output 
(I/O) function on Burroughs computer systems that support Universal I/O 
(UIO) on Message-Level Interface Processor (MLIP) systems (A3, A 3K, 
A 9, A 10. B 5900, and B 6900). This manual is primarily intended as an 
introduction for systems programmers who will later study the software 
implementation of Physical I/O, but it may also be of interest to those 
for whom an overview of the major components involved in the I/O process 
is sufficient. It is assumed that the reader is familiar with the basic 
structure and function of the Master Control Program (MCP) and the New 
Programming (NEWP) language, although knowledge of the details of the 
MCP and of the machine architecture is not required. 



The PHYSICALIO module of the MCP is the central component in the 
Physical I/O process. There are four versions of this module, the 
appropriate one of which is selected during system initialization 
according to the type of I/O subsystem the machine supports: 

1. MLIP (A3, A 3K, A 9, A 10, B 5900, and B 6900 systems) 

2. Multiplexor (B 6800 systems) 

3. I/O Module (B 7700 and B 7800 systems) 

4. Host Data Unit (HDU) (A 15 and B 7900 systems) 



The four versions of the PHYSICALIO module have the same interface to 
the rest of the MCP, freeing the majority of the MCP from having to 
handle the idiosyncrasies of four different I/O subsystems. Only the 
MLIP module version is described in this manual. 



The systems using the MLIP I/O subsystem are divided into two groups; 

1. The A3, A 9, B 5900, and B 6900 systems 

2. The A 3K and A 10 systems 



The basic I/O process is the same for these systems, but some of the 
procedures, mechanisms, and data structures used by the MLIP I/O 
subsystem for each group are different. The systems are identified when 
a distinction must be made between the two groups of systems. 



The A 3K system has a dual processor configuration but can function with 
only one processor working. Other A 3 models are single-processor 
systems. 



PHYSICAL I/O OVERVIEW 

NOTE 

This document is not Intended to be a 
coiTiplete specification of the Physical 
I/O implementation for MLIP systems. 
Most specific details and exception 
conditions have been omitted for brevity 
and to better highlight the general 
structure of the I/O software and 
hardware. Although the overall design is 
stable, trie details of the implementation 
are subject to change from Mark. Release 
to Mark. Release. 
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STRUCTURE OF THIS MANUAL 

Sections 



INTRODUCTION 

The purpose of this overview is described, and the PHYSICALIO module 
versions are listed. 



SYSTEM OVERVIEW 

The general I/O path between the MCP and the UIO subsystem is 
described and illustrated. 



MCP REQUESTORS 

The MCP modules that interface with PHYSICALIO to initiate I/Os and 
to request unit information are described. 



REQUESTOR/PHYSICALIO INTERFACE 

Input/Output Control Block (lOCB) and unit interfaces that exchange 
information between the MCP and the PHYSICALIO module are described. 



PHYSICALIO MODULE 

PHYSICALIO' s responsibilities for I/O processing, exception 
handling, and responding to unit inquiries are described. 



PHYSICALIO/MLIP INTERFACE 

The mechanisms that are used to communicate between PHYSICALIO and 
the MLIP are described. The mechanisms and data structures 
described are lOCBs, Communicate with Universal I/O (CUIO) operator, 
Signal Processing Element Set (SPES) operator, lOCB queue, command 
queue, unit queue, MLIP I/O Table, horizontal queue, result queue, 
and I/O Finish interrupt. 



MLIP 

The functions of the MLIP are listed and MLIP commands are 
described. 
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8 MLIP/UIO INTERFACE 

The Message-Level Interface (MLI) (the mechanism used to allow 
communication between the MLIP and the UIO subsystem) and the 
actions performed when an I/O is transferred to a DLP are described. 

9 UIO SUBSYSTEM 

The rules and conventions used to establish a valid UIO subsystem 
configuration are described. The host, UIO base. Data Link. 
Processor (DLP), unit, and path are identified as parts of a UIO 
subsystem configuration. 

10 SYSTEM INITIALIZATION 

The initialization procedures for the UIO subsystem are described. 

11 PERIPHERAL STATUS 

The method of monitoring a peripheral's status is described. 

12 DATA COMMUNICATIONS 

Data communication landled by special-purpose DLPs — Network. Support 
Processors (NSPs), Line Support Processors (LSPs), and Data 
Communications Data Link Processors (DC-DLPs) — in the I/O subsystem 
is described. 

Appendix 

A glossary appears at the end of this manual. 
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SYSTEM OVERVIEW 



The PHYSICALIO module is the Master Control Program's (MCP) interface to 
the I/O subsystem. PHYSICALIO provides two notable functions relating 
to the I/O subsystem: the handling of I/Os and the management of units. 
Units are peripheral devices such as printers, magnetic tape drives, 
card readers, and so on. 



MAJOR COMPONENTS 



Figure 1 shows the basic flow of information between the MCP and the I/O 
subsystem: 
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Figure 1. Information Flow between MCP and UIO Subsystem 



PHYSICAL I/O OVERVIEW 
Most I/Os follow this s :andard path through the system: 

1. An MCP requestor calls the PHYSICALIO module to perform a 
specific I/O operation. 

2. The PHYSICALIO module builds a data structure representing the 
operation to be performed and calls the MLIP. 

3. The MLIP interprets the data structure, generates an I/O 
request , and passes it to the UIO subsystem. 



The results of the I/O :'ollow the reverse path, from the UIO subsystem 
to the MLIP to PHYSICALIO to the requestors. 



Each of the components and interfaces shown in Figure 1 will be 
discussed later in the manual. However, because the structure and 
terminology of the UIO subsystem may be unfamiliar to some readers, a 
brief functional description of the UIO subsystem is presented here. 



System Overview 



UIO FUNCTIOWAL OVERVIEW 



Figure 2 illustrates the configuration of components used to pass data 
from the MLIP to the UIO bases. 
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Figure 2. MLIP-to-UIO-Base Configuration 

Each processor uses an MLIP and associated hardware to pass an I/O to a 
peripheral. The following is a typical I/O path from an MLIP to a DLP. 

1. MLIP 

2. MLI ports 

3. MLI 

4. UIO base 

5. Data Link. Processors (DLPs) 



Each base contains one or more DLPs, which can connect either directly 
to the peripheral or to a peripheral controller (depending on the type 
of peripheral). In addition, each base includes the components 
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PHYSICAL I/O OVERVIEW 
necessary to route messages between the DLPs and the host. 



There is, in general, a different type of DLP for each type of 
peripheral. In Figure 3, a Train Printer DLP (TP-DLP) is shown 
connected to a train printer, a Card Reader DLP (CR-DLP) is shown 
connected to a card reader, and a Host Transfer DLP (HT-DLP) is shown 
connected to a Disk. Pack Drive Controller (DPDC). 
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Figure 3. MLIP-through-DLP Configuration 



Figures 2 and 3 are schematic and do not necessarily represent actual 
configuration possibilities, restrictions, or limits. A more detailed 
description of UIO subsystem configurations is contained in the "UIO 
Subsystem" section of this manual. 



See also 

UIO Subsystem 



73 
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MCP REQUESTORS 



The PHYSICALIO module provides the following services to the rest of the 
Master Control Program (MCP): maintaining unit information. Initiating 
I/Os, monitoring peripheral status, and initializing Data Link. 
Processors (DLPs). This section describes the MCP modules that 
interface with PHYSICALIO to initiate I/Os and to request unit 
information. Peripheral status and system initialization are described 
in later sections. 



See also 

Peripheral status 91 

System Initialization 87 



I/O REQUESTORS 



All I/Os required by the MCP, except some I/Os performed early in the 
system initialization process, are initiated by calling the PHYSICALIO 
module. The programmatic mechanism of communication between the 
requesting modules shown in Figure 4 and the PHYSICALIO module is 
described in the next section. 



MCP I/O Requestors 



Logical I/O 



Memory Manager 



Library Maintenance 



Task. Manager 

Datacomm 



Other 
Modules 



Maintenance 

Job Controller 



AUTOBACKUP 



Sort 
I 



PHYSICALIO Module 



Figure 4. PHYSICALIO and Requesting Modules 
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PHYSICAL I/O OVERVIEW 

Although there are many modules that call PHYSICALIO, PHYSICALIO views 
these requestors as members of certain categories or sets. These sets 
are based on the distinctions required to properly handle the I/O 
request, not on the Identity or function of the module requesting the 
I/O. Some distinctions :hat PHYSICALIO mak.es based on the type of 
requestor are whether or not to allow access to privileged information 
or operations, whether o:' not to attempt error recovery, and whether or 
not to log errors. 



As far as PHYSICALIO is concerned, all I/Os fall into one of 
I/O requestor sets: 



four main 



I/O Set 



Descr Lption 



User 



I/Os initiated on behalf of a user program. Logical 
I/O and library maintenance are two areas in the MCP 
that request user I/Os. 



MCP 



The general category of I/Os initiated to perform MCP 
functions. Memory management, SWAPPER, Datacomm, and 
AUTOBACKUP request MCP I/Os, as do many other 
functions in the MCP. 



Maintenance 



I/Os initiated primarily by the maintenance module to 
perform I/O hardware diagnostic functions. 



Kernel 



I/Os initiated by PHYSICALIO itself to perform such 
functions as retrying errors and determining 
peripheral status. 



Because a value representing the type of requestor is passed to 
PHYSICALIO With each I/O request, a requesting module can initiate I/Os 
with different requestor values for different purposes. For example, 
the maintenance module initiates maintenance I/Os when it performs 
diagnostic tests and user I/Os (through logical I/O) when it displays 
the results of those tes:s. 



The four main I/O reques :or sets (described above) comprise several 
specific requestor values. These values allow PHYSICALIO to make more 
specialized distinctions when desirable and can be regrouped into 
additional sets. 
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MCP Requestors 

When the distinction between user I/Os and MCP I/Os Is important (for 
example, in exception handling), PHYSICALIO tests the requestor value 
for membership in either the user I/O set or the MCP I/O set. 



When special handling is required for library maintenance I/Os (for 
example, in retrying parity errors), PHYSICALIO tests the requestor 
value for membership in the library maintenance I/O set. 
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UNIT INFORMATION REQUESTORS 



Many of the 
information 
are sent. 
Datacomm, 
related to 
of units 
Information 
is appropr 
maintain su 



same module 
about and. 
Some of tY 
and AUTOBAC 
PHYSICALIO i 
and the co 

is "logical 
lately mair 
eh informati 



s that request I/Os to be performed also require 
/or some control over the units to which the I/Os 
ese requestors are Logical I/O, Maintenance, 
KUP. In addition, some modules are functionally 
n that they maintain information about the status 
nfiguration of the I/O subsystem. Much of this 
," as opposed to "physical," in nature and, thus, 
tained outside of PHYSICALIO. Three modules that 
on are described below. 



FILEFINDER Module 



The FILEFINDER module locates an input or output device upon request. 
FILEFINDER maintains the UNIT table, which contains data about each 
unit. Although most of the information is updated during the 
performance of other logical functions (such as reading labels, 
assigning units to tasks, and reserving units), information pertaining 
to the current physical status of a unit is obtained by calling 
PHYSICALIO. 



UNITID Module 



The UNITID module reads and writes labels on labeled units. These 
functions require that UNITID request unit information from PHYSICALIO. 
UNITID maintains the U3NF0 table, which contains label information for 
each unit. 



MCPSTATUS Mo dule 



The MCPSTATUS module displays and alters unit information through the 
SYSTEMSTATUS , GETSTATUS , and SETSTATUS Interfaces. These functions 
require that MCPSTATUS call PHYSICALIO to obtain and to alter 
unit-oriented information. 



Other functional areas that require unit information include disk, 
allocation, disk file' management, directory control, and configuration 
control. 
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REQUESTOR/PHYSICALIO INTERFACE 



The Master Control Program (MCP) requestors exchange information with 
the PHYSICALIO module through a group of interface procedures that are 
exported by the PHYSICALIO module. The names of these procedures are 
identical for all four PHYSICALIO version modules, so that the majority 
of the MCP is not required to distinguish between the possible I/O 
subsystems. 



The two primary categories of interface procedures 
Control Block (lOCB) interfaces and unit interfaces. 



are Input/Output 



lOCB INTERFACE PROCEDURES 



The I/O request interface between PHYSICALIO and the Message-Level 
Interface Processor (MLIP) is a data structure called an lOCB. 
PHYSICALIO allocates and manages lOCBs, which allows the format of lOCBs 
and the mechanism for their allocation to vary without impact on the 
rest of the MCP. Some of the information required in the lOCB is 
provided by the requestor through interface procedures and some is 
inserted by PHYSICALIO before actually starting the I/O. After 
processing the I/O, the MLIP places result information into the lOCB; 
PHYSICALIO interprets this Information and generates a logical result 
descriptor, which is accessible to the requestor through an interface 
procedure. 



As far as the requestor is concerned, there are three stages in the I/O 
process : 

1. Allocating the lOCB 

2. Performing one or more I/Os using that lOCB 

3. Deallocating the lOCB 



Performing I/Os involves providing the proper parameters to PHYSICALIO 
and acting on the result information. The following pages describe the 
interface procedures provided for lOCB-related actions. 



Ifc 



PHYSICAL I/O OVERVIEW 



Setting Up an IOCS 



lOCBs are allocated when the requestor calls BUILDIOCB. BUILDIOCB 
stores a "mom" descriptor of the new lOCB in a location specified by a 
reference passed as a parameter to BUILDIOCB. To initiate the I/O once 
the lOCB has been allocated, the requestor must provide PHYSICALIO with 
the following information: 

A reference to the lOCB 

An I/O Control Word (lOCW) describing the operation to be 
performed 

A buffer for the data 

- An offset into the buffer indicating the start of the area 
available for pos:3ible data transfer 

- The length of the area available for possible data transfer 

- A mask with bits :3et to indicate the exception conditions under 
which PHYSICALIO is not to attempt recovery 

- The unit number o:' the unit to which the I/O is to be directed 

- A value representing the requestor type 

If the I/O is to be performed asynchronously (that is, while the 
requestor continues executing), another piece of information is 
required: 

- A reference to an event to be caused when the I/O has finished 

If the I/O is a user I/O, an additional parameter is required: 

- A reference to the File Information Block (FIB) of the lOCB 



Because information chan;?es from one I/O to the next in most cases, all 
of this information i;; passed to PHYSICALIO when I/O initiation is 
requested. However, in :3ome cases, most notably for normal (nondirect) 
user I/Os requested through logical I/O, the information is relatively 
constant from one I/O operation to the next. Several interface 
procedures are provided to allow many of the I/O parameters to be set 
before the I/O initiation is requested; thus, information for the lOCB 
is transferred only when it changes. 
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Requestor/PHYSICALIO Interface 

For a requestor such as logical I/O, the interface procedures called 
"SET<itein>" (such as SETIOMASK) would be called between I/Os to alter 
only the lOCB information that must change before the next I/O. The I/O 
initiate procedure for these I/Os (described in "Initiating an I/O") 
requires very few parameters because most of the information has already 
been stored in the lOCB. 



Initiating an I/O 



Many interface procedures are provided for initiating I/Os. The most 
important characteristics of each procedure can be readily identified by 
each procedure name. 



The first part of each procedure name is either INITIATE or DO. 
INITIATE procedures initiate an I/O asynchronously; that is, control is 
returned to the requestor after the I/O is initiated without waiting for 
the I/O to finish. DO procedures initiate an I/O and wait until the I/O 
finishes before returning control to the requestor. 



The second part of each procedure name contains one or more of the 
following keywords: 



Keyword 



Type of I/O 



CHAR 

WORD 

MEMORY 

USER 

MAINTENANCE 

DIRECT 

PSEUDO 

KERNEL 



A Character-oriented I/O 

A 48-bit-word-oriented I/O 

A 51-bit-word-oriented I/O 

A user I/O 

A maintenance I/O 

A direct I/O 

An I/O not actually to be performed; the requestor is 
calling PHYSICALIO Just for book-keeping purposes 

A kernel I/O 



'10" is appended to complete the procedure name. 
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PHYSICAL I/O OVERVIEW 

Not all combinations of these keywords represent actual interface 
procedures because many of the combinations are not required. The 
following identifiers are examples of I/O initiation interface 
procedures: DOCHARIO, DOMEMORYIO, INITIATEUSERIO, INITIATEUSERDIRECTIO, 
INITIATEDIRECTPSEUDOIO. 



Accessing Information in an IOCS 



The information in an IOCS cannot be accessed or changed while the I/O 
is in process. A Boolean interface procedure called lOINPROCESS allows 
the requestor to determi:ie whether or not the I/O is still active. 



If the I/O is not in process, various items stored in the lOCB can be 
requested through the "GET<item>" interface procedures. For example, 
GETIOTIME returns the I/O time stored in the IOCS. GETLOGICALRESULT 
returns a "soft" result descriptor that is common for all I/O 
subsystems. This result is similar in content to the STATE file 
attribute. 



Deallocating an IQCB 



An lOCB is deallocated bv calling the interface procedure FORGETIOCB. 
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Requestor/PHYSICALIO Interface 
UNIT INTERFACE PROCEDURES 



The unit interface procedures allow PHYSICALIO and the requestors to 
exchange Information about the status and visibility of the I/O units. 
Information about a particular unit Is requested by specifying a unit 
number, as described below. 



Each unit has two unique unit numbers: a logical unit number and a 
physical unit number. Logical unit numbers are used within the MOP for 
two major reasons: 

1. Logical unit numbers refer only to units for which there is a 
Data Link Processor (DLP) physically present (rather than 
referring to the entire tree of addressable units). This makes 
the UNIT tables much smaller than they otherwise might be. 

2. Logical unit numbers allow a physical unit to "move" without 
affecting its logical connection to the MOP. 



Phi'-sical unit numbers are used when the MCP communicates with the system 
operator or the I/O subsystem. PHYSICALIO maintains the correspondence 
between logical and physical unit numbers. 



The following paragraphs describe some of the major unit interface 
procedures . 



TAtOSUNIT and GIVEUNIT 



TAKEUNIT and GIVEUNIT are important interfaces for coordinating the 
transfer of a unit's logical control from PHYSICALIO to its requestors 
(T/JCEUNIT) and from the requestors back to PHYSICALIO (GIVEUNIT). 



For single-user devices (for example, train printers), TAKEUNIT is 
called when the unit is assigned to a task and GIVEUNIT is called when 
the unit becomes unassigned. For multiple-user devices (for example, 
disk packs), TAKEUNIT is called before the label is read and GIVEUNIT is 
called in response to an Operator Display Terminal (ODT) command (such 
as CLOSE and UR) . 



Two of the parameters to GIVEUNIT indicate whether or not PHYSICALIO 
monitors peripheral status for the unit and, if so, whether or not the 
unit is logically ready. The initiation of peripheral status monitoring 
is described in the "Peripheral Status" section. 
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GETUKITIHFO and SETUKITINFO 



These procedures allow the requestors to access and, in some cases, 
alter various items of unit information. For example, GETUNITINFO will 
return the unit's subtype, an indication of whether or not there is a 
path to the unit, or the unit's reliability factor, depending on the 
item requested by the procedure's selection parameter. 



GETLOGICALUHITSTATUS 



This procedure returns device-dependent information about the unit; for 
a train printer, for example, GETLOGICALUNITSTATUS will indicate whether 
or not a TRAIN table ha; been loaded, and for a magnetic tape, whether 
or not the tape is rewinding. 



See also 

Peripheral Status 91 
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PHYSICALIO MODULE 



The PHYSICALIO module participates in system initialization by creating 
and maintaining the configuration tables describing the I/O subsystem. 
This topic is described in the "System Initialization" section. 
PHYSICALIO also monitors peripheral status, which is discussed in the 
"Peripheral Status" section. PHYSICALIO' s responsibilities in the areas 
of I/O processing, exception handling, and responding to inquiries about 
units are described in the following paragraphs. 



PROCESSING OF I/Os 

The PHYSICALIO module provides two methods of I/O initiation for the 
Message-Level Interface Processor (MLIP) I/O subsystem. 

1. One method supports the A 3, A 9, B 5900, and B 6900 systems. 

2. The other method supports the A 3K and A 10 systems. 



Both methods of I/O initiation are discussed in this section. The 
systems are identified when the I/O processing method is unique to a 
systems group. 



At Initialization time, the Master Control Program (MCP) interrogates 
the result of the WATI operator to determine which I/O method is used on 
the system. The WATI operator identifies the system in use and provides 
implementation-level information about the system. 



The result of the WATI operator determines which I/O initiation method 
to use for the system. The I/O initiation method in turn determines 
whether or not the Communicate with Universal I/O (CUIO) operator is 
valid for the system. The CUIO operator is used to pass the address of 
an Input/Output Control Block. (lOCB) to an MLIP for initiation. The 
CUIO operator is used in the A3, A 9, B 5900. and B 6900 systems and is 
described in "CUIO Operator." On A 3K and A 10 systems, an I/O is issued 
by queuing an lOCB to an lOCB queue and using the Signal Processing 
Element Set (SPES) operator to signal the MLIP. The SPES operator is 
described in the "PHYSICALIO/MLIP Interface" section. 
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I/O Processing for A 3^ A 9^. B 5900. and B 6900 Systems 



The I/O processing method for A3, A 9, B 5900, and B 6900 systems 
through the PHYSICALIO module is described by the following example. 
INITIATECHARIO was chos(?n as the interface procedure for the I/O 
initiation example becauj;e it is a commonly used interface for MCP I/Os. 
At decision points in the processing, the most straightforward choice is 
talcen. For example, ;.t is assumed here that the I/O was completed 
without exceptions (exception handling is described in "Exception 
Handling"). 



Elxample 

1. After allocating an lOCB through BUILDIOCB, the requestor calls 
INITIATECHARIO, passing in the following required parameters: 

a. The lOCB 

b. A reference to the event to be caused when the I/O 
finishes 

c. The requestor type 

d. An I/O exception mask. 

e. An Input/Output Control Word (lOCW) 

f. A buffer 

g. An index into the buffer 
h. An I/O length 

i. A unit number 

2. INITIATECHARIO marks the lOCB "in process," stores the 
parameters in the lOCB, and calls INITIATEIO. 

3. INITIATEIO coordinates the remainder of the I/O initiation 
processing by calling SETUPIOCB, GETPATH, and FIREIOCB. 

4. SETUPIOCB converts the lOCW into the appropriate operation code 
for the Universal I/O (UIO) subsystem and sets up the 
information required for the proper queuing of the lOCB by the 
MLIP. 

5. GETPATH selects a path to the unit and inserts the path 
information into the lOCB. 
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FIREIOCB marks the lOCB "active" and gives the lOCB to the MLIP 
through the CUIO operator. 



The I/O is now in progress. The following actions occur when the MLIP 
informs the MCP that the I/O has been completed. 

7. HARDWAREINTERRUPT is invoked when the I/O Finish interrupt is 
received from the MLIP; HARDWAREINTERRUPT calls IOFINISH68. 

Because the I/O Finish interrupt does not designate which I/O 
has completed, I0FINISH68 searches through the result queues to 
find completed I/Os. When one is found, IOFINISH68 selects the 
appropriate routine to handle the completed I/O; in most cases 
(in particular, when there are no exceptions reported), it 
calls FINISHIO. 

8. FINISHIO determines whether or not it is running on the 
processor that initiated the I/O. If so, it calls FINISHOFFIO. 

9. FINISHOFFIO Inserts into the logical result descriptor a value 
indicating the number of units transferred, computes and bills 
the I/O time, sets the state of the lOCB to "inactive," and 
causes the I/O completion event, a reference to which was 
passed as a parameter to the interface procedure. 



At this point, the requestor has been notified that the I/O has 
completed and it can now access result information in the lOCB. 



See also 

I/O Finish Interrupt 62 



I/O Processing for A SK and A 10 Systems 



The I/O processing method for A 3K and A 10 systems is similar to the 
method described above, except that the procedure names are different 
and additional procedures were created. The procedures that perform the 
same functions as the method above are INITIATEIO_ASIO, FIREIOCB_ASIO, 
and IOFINISH_ASIO. INITIATEDATACOMIO_ASI0 and PATHRES_ASIO are new 
procedures that perform ancillary functions for data communication 
operations and path reservation. 



In the following example, the requestor calls INITIATECHARIO for I/O 
initialization. As in the example above, the same parameters are passed 
to the allocated lOCB. 
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INITIATECHARIO marks the lOCB in process, 
in the lOCB, and calls INITIATEIO_ASIO. 



stores the parameters 



2. INITIATEIO_ASIO coordinates the remainder of the I/O initiation 
processing by calling SETUPIOCB. The path to the peripheral 
device is eithijr specified by GETPATH or determined by the 
optimization di?fines. When the path is selected, FIREIOCB_ASIO 
is called. 

3. SETUPIOCB converts the lOCW into the appropriate operation code 
for the UIO subsystem and sets up the information required for 
the proper queuing of the lOCB by the MLIP. 

4. The path to a peripheral device can be selected by the MCP 
through GETPATH, or if the Simple Path Selection field in the 
MLIP Control Word of the lOCB is set to TRUE, then the MLIP 
uses the path specified in the Path Table Pointer word of the 
unit queue. I:' GETPATH is used, the path Information is 
inserted into ':he lOCB. 

5. FIREIOCB_ASIO marks the IOCS "active" and gives the lOCB to the 
MLIP by queuinji it in the lOCB queue. 



The I/O is now in progress. The following actions occur when 
informs the MCP that the I/O has completed. 



the MLIP 



HARDWAREINTERRUPT is invoked when the I/O Finish interrupt is 
received from the MLIP; HARDWAREINTERRUPT calls IOFINISH_ASIO. 

Because the I/O Finish interrupt does not designate which I/O 
has been completed, IOFINISH_ASIO searches through the result 
queues to find completed I/Os. When one is found, IOFINISH_ASIO 
selects the appropriate routine to handle the completed I/O; in 
most cases (::n particular, when there are no exceptions 
reported), it calls FINISHIO. 

FINISHIO calls FINISHOFFIO. 

FINISHOFFIO inserts into the logical result descriptor a value 
indicating the number of units transferred, computes and bills 
the I/O time, fsets the state of the lOCB to "inactive," and 
causes the I/O completion event, a reference to which was 
passed as a parameter to the interface procedure. 



At this point, the requestor has been notified that the 
completed and it can now access result Information in the lOCB. 



I/O has 
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See also 

I/O Finish Interrupt 62 

lOCB 33 
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EXCEPTION HAMDLIMG 



The following paragraphs describe how PHYSICALIO handles I/Os that are 
completed with exceptions. The exception-handling mechanism is 
discussed in general terms, ignoring most device dependencies. Although 
handling of device dependencies is really the largest part of the 
exception-handling task., the basic algorithm is similar for most 
devices. For the following situations, the A 3, A 9, B 5900, and B 6900 
systems' I/O subsystem uses IOFINISH68 and the command queue, and the 
A 3K and A 10 systems' I/O subsystem uses IOFINISH_ASIO and the unit 
queue. 



Regardless of whether or not the I/O is completed normally, 
HARDWARE INTERRUPT calls IOFINISH68 or IOFINISH_ASIO, depending on which 
I/O processing method is used, to handle the I/O Finish interrupt. When 
I0FINISH68 or IOFINISH_ASIO determines that an exception condition has 
occurred, in most cases it calls lOEXCEPTION to take the appropriate 
action . 



lOEXCEPTION calls BUILDLOGICALRD, Which returns a logical result 
descriptor generated by analyzing the physical results received from the 
Data Link. Processor (DLP) and the MLIP. Back in lOEXCEPTION, the 
logical result is then masked with the I/O mask that the requestor 
passed as a parameter to the I/O initiation procedure; this process may 
eliminate some exception conditions from consideration. The masked 
result is then further masked, this time to eliminate exception 
conditions that do not require handling by PHYSICALIO. 



If no exceptions remain after masking the logical result, lOEXCEPTION 
activates the suspended command queue or unit queue, depending on the 
I/O processing method used by the MLIP I/O subsystem (see "Command 
Queue" and "Unit Queue"), and calls FINISHIO to complete the processing 
of the lOCB (see "Processing of I/Os"). If the only exceptions that 
remain are simple enough to be handled in lOEXCEPTION (for example, 
end-of-page on a printer), lOEXCEPTION takes the appropriate action. 
However, if a more serious exception remains to be handled, lOEXCEPTION 
calls lOERROR. 



lOERROR selects a retry procedure based on the type of unit to which the 
original I/O was directed. The retry procedure retries the I/O 
operation until the operation is successful, until an irrecoverable 
error occurs, or until the retry limit is reached. At this point, 
lOERROR logs the original error and its retry history. In most cases, 
lOERROR then calls FINISHIO to return the lOCB to the requestor and 
activates the corairiand queue or unit queue that was suspended by the MLIP 
because of the original exception. 
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See also 

Command Queue 42 

Processing of I/Os 21 

Unit Queue 48 



PHYSICAL I/O OVERVIEW 
UNIT INFORMATION 



The unit information inti^rface procedures access and alter items in 
PHYSICALIO's unit information tables, the most important of which are 
UNITCONTROL, UNITMAP, an.J UNITSTATUS. 



UNITCONTROL Table 



The UNITCONTROL table contains information used in making decisions 
about the management of units. This information includes the unit type, 
the "ownership" of the unit (in the TAKEUNIT/GIVEUNIT sense), and 
special status informa-:ion for the unit. GETUNITINFO references this 
table to return information as to whether or not the unit is being 
moved, whether or not the unit has been disabled (through BLASTUNIT), 
v;hether or not the unit is the Halt/Load unit, whether or not the 
initiation of I/O operations to the unit has been suspended because the 
unit has encountered an end-of-file condition, and so on. 



UNITMAP Table 



The UNITMAP table maintains the correspondence between logical and 
physical unit numbers. When GETUNITINFO is requested to return logical 
or physical unit numbers, it accesses this table. 



UNITSTATUS Table 



The UNITSTATUS table contains the logical and physical ready/not-ready 
status for each unit and the paths to those units. When GETUNITINFO is 
requested to return a va:.ue indicating whether or not the specified unit 
exists or whether or not there is a path to the unit, GETUNITINFO 
accesses this table. 
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6 PHYSICALIO/MLIP INTERFACE 

The; Master Control Program (MOP) communicates with the Message-Level 
Interface Processor (MLIP) through the PHYSICALIO module. The A 3, A 9, 
B 5900, and B 6900 systems use the following mechanisms for processing 
I/O between PHYSICALIO and the MLIP: 

- The Communicate with Universal I/O (CUIO) operator 

- Shared data structures, which Include Input/Output Control Blocks 
(lOCBs), command queues, horizontal queues, and result queues 

- The I/O Finish interrupt 



The A 3K and A 10 systems use the following mechanisms for processing 
I/O between PHYSICALIO and the MLIP: 

- The Signal Processing Element Set (SPES) operator/IOCB queue 

- Shared data structures, which include lOCBs, lOCB queue, unit 
queues, MLIP I/O Tables, horizontal queues, and result queues 

The I/O Finish interrupt 



The following describes how these mechanisms are used to initiate, 
process, and complete an I/O at the MLIP level for both groups of 
systems . 
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MECHANISMS FOR A 3^ A 9 ^ B 5900. AND B 6900 SYSTEMS 



An lOCB represents an I/O operation to be performed. When PHYSICALIO 
has inserted into an lOCB the information required by the MLIP to 
perform an I/O, the CUIO operator is executed to pass the memory address 
of the lOCB to the MLIP. The MLIP then queues the lOCB into a command 
queue, from which the I DCB is later Initiated. If the MLIP attempts to 
initiate an lOCB to a busy Data Link Processor (DLP), the command queue 
may be temporarily link.?d into a horizontal queue. When an lOCB is 
initiated, it is unlinked from the command queue. When the I/O 
operation associated with an lOCB finishes, the IOCS is linked into a 
result queue. The MLIP then determines whether or not an I/O Finish 
interrupt should be generated to Inform the processor that an lOCB has 
finished. 



The following data structures are used for PHYSICALIO/MLIP communication 
in the A3, A 9, B 5900, and B 6900 systems and are set up by the MCP 
for the MLIP: 

- Command queue. k list of lOCBs that are to be initiated, usually 
to the same unit. 

Horizontal queue. Mechanism for queuing command queues when the 
DLP path to the unit is busy. 

- Result queue. A list of completed lOCBs. A result queue is 
built for each processor. 



The PHYSICALIO/MLIP interfaces are described individually on the 
following pages. Because the handling of MLIP I/O subsystem errors may 
involve all of the interface mechanisms described here, error handling 
is discussed in "MLIP Error Handling," following the descriptions of the 
interfaces . 



See also 

Command Queue 42 

Horizontal Queue 58 

Result Queue 60 



PHYSICALIO/MLIP Interface 
MI-:CHAMISMS FOR A 3K AST) A 10 SYSTEMS 



After PHYSICALIO inserts the information required by the MLIP to perform 
an I/O into an lOCB, PHYSICALIO locks the lOCB queue, queues the lOCB to 
the tail of the lOCB queue, and unlocks the lOCB queue. If the lOCB 
queue is empty when the lOCB is queued to it, PHYSICALIO uses the SPES 
operator to send the MLIP an Initiate I/O signal. 



When the MLIP receives the Initiate I/O signal, the signaled MLIP locks 
the lOCB queue, takes the lOCB at the head of the lOCB queue, locks the 
unit queue specified by the lOCB, and then unlocks the lOCB queue. 



If the lOCB queue contains more lOCBs, the MLIP sends the Initiate I/O 
signal to the other MLIPs specified in the MLIP Destination Set (Word 6) 
of the MLIP I/O table (see "MLIP I/O Table"). The MLIP then queues the 
lOCB to the unit queue. If the lOCB is queued at the head of the unit 
queue, the MLIP initiates the unit queue. If the MLIP attempts to 
initiate an lOCB to a busy DLP, the unit queue is temporarily linked 
into a horizontal queue. 



When the I/O is finished, the MLIP puts the lOCB into the appropriate 
result queue. After queuing an lOCB into an empty result queue, the 
MLIP uses the EMP Destination Set (Word 5) of the MLIP I/O table to 
signal one of the E-Mode processors (EMPs) in the set to handle an I/O 
Finish (see "MLIP I/O Table"). 



Because processing elements (data and I/O) share data structures, access 
to the data structures Is synchronized through a lock bit in the lock 
word of each data structure. 



The lOCB queue is locked by MLIPs and the MCP. All other data 
structures are locked by the MLIP only. After successfully locking and 
using the data structure, the MLIP or MCP writes the lock word back to 
memory, which unlocks the data structure. 



The following data structures are used for PHYSICALIO/MLIP communication 
in the A 3K and A 10 systems and are set up by the MCP for the MLIP: 

- lOCB queue. Used by PHYSICALIO to send lOCBs to the MLIPs. 

Unit queue. Allocated such that all I/Os for one unit go through 
the assigned unit queue, regardless of the number of paths to the 
unit . 
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MLIP I/O table. Contains the MLIP queue and other information 
used by the MLIP. The MLIP uses the MLIP queue to pass unit 
queues to other MLIPs. There is one MLIP queue in each MLIP I/O 
table and one MLIP I/O table for each MLIP in the partition. 
There are several words in the table. The EMP and MLIP 
destination set words in the table indicate which processing 
elements are available for I/O processing. The other words in 
the table are described when necessary for the overview. 

Horizontal queue. Mechanism for queuing unit queues when the DLP 
path to the unit is busy. 

Result queue. A list of completed lOCBs. Only one result queue 
is initialized. 



The MLIP uses disk seek optimization to increase I/O throughput. Disk 
seek optimization is performed during the Initiation of the lOCB from 
the unit queue. It selects the lOCB that specifies a disk address 
closest to the current position of the disk head. Disk seek 
optimization depends on the single point of control provided by unit 
queues. 



The PHYSICALIO/MLIP interfaces are described individually on the 
following pages. Because the handling of MLIP I/O subsystem errors may 
involve all of the interface mechanisms described here, error handling 
is discussed in "MLIP Error Handling," following the descriptions of the 
interfaces . 



See also 

Horizontal Queue 58 

lOCB Queue 41 

MLIP I/O Table 56 

Result Queue 60 

Unit queue 48 
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lOCB 



An lOCB is an MCP-allocated memory area that either contains or 
references all of the information required by the MLIP to perform an I/O 
operation. It also contains areas that are used by the MLIP to 
te;mporarlly store information during the processing of an I/O and to 
return information to PHYSICALIO when the I/O has finished. This 
information is formatted into the 15 lOCB words shown in Table 1. The 
table also shows which lOCB words are assigned meaningful (nonzero) 
values by the MCP prior to initiation of the lOCB and which are assigned 
values by the MLIP during processing of the lOCB. 



Word 0: 
Word 1; 
Word 2; 
Word 3: 
Word 4; 
Word 5! 
Word 6; 
Word 7; 
Word 8: 
Word 9: 
Word 10: 
Word 11: 
Word 12: 
Word 13: 
Word 14: 



Table 1. lOCB I/O Table 



Values Assigned by 
MCP MLIP 



MLIP Control Word 
DLP Address Word 



Command or Unit Queue Header Pointer 
lOCB Self Pointer 



DLP I/O Command Pointer 
DLP I/O Result Pointer 



DLP Command/Result Lengths 
Result Mask. 



Result Queue Head Pointer 
Next lOCB Link. 



MLIP Current Data Area Pointer 
MLIP Current I/O Length 



MLIP State and Result 
I/O Start Time 
I/O Finish Time 



Sk 



PHYSICAL I/O OVERVIEW 

The actual lOCB, as allocated by the MCP, is longer than 15 words. The 
additional space is used by the MCP to store information about the MCP's 
processing of I/O; for €>xainple, a reference to the event to be caused 
when the I/O finishes is: kept in the MCP portion of the lOCB. 



The following describes how each of the 15 MLIP-visible lOCB words, and 
their fields, is used by the MCP and the MLIP. References to the 
command queue apply to the A3, A 9, B 5900, and B 6900 systems; 
references to the unit ciueue apply to A 3K and A 10 systems. 

MLIP Control Word 

Word contains, several fields set by the MCP to specify the 
I/O operation to be performed. The fields are described below, 
and an example of the MCP's use of each special-purpose field 
is provided. 

lOCB Mar:< 

This field contains the code 4'IOCB', which marks the word 
as the first word of an lOCB. 

Queue at Head 

When this one-bit field is TRUE, the MLIP will queue the 
lOCB at the head of the command queue or unit queue. One 
use of this feature is to perform retry I/Os when a 
device-oriented error has occurred. 

MLIP/DLP Commard 

When this one-bit field is TRUE, the lOCB contains a 
command to be interpreted by the MLIP itself; the MLIP 
command is contained in the first word pointed to by the 
DLP I/O Command Pointer (Word 4) in the lOCB. The MLIP 
operations that the MCP can request are described in the 
"MLIP" section. 

When this one-bit field is FALSE, the lOCB contains a 
command for the DLP referenced by the DLP Address Word 
(Word 1) of the lOCB. 

Attention 

When this one-bit field is TRUE, the MLIP will set both 
the Attention and the Exception fields in the MLIP result 
(see "MLIP State and Result" below). This field forces 
the command queue or unit queue to be suspended upon 
completion of the I/O operation, or ensures that the I/O 
will be processed by the exception handling routines. For 
example, all binary card reads are initiated with the 
Attention field set to TRUE, because lOEXCEPTION is 
responsible for recognizing the binary end-of-file card 
(see "Exception Handling"). 
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Cause I/O Finish Interrupt 

When this one-bit field is TRUE, the MLIP will 
unconditionally cause an I/O Finish interrupt when the I/O 
completes. When this one-bit field is FALSE, the MLIP 
will make the decision as to whether or not to cause an 
interrupt based on other conditions (see "I/O Finish 
Interrupt") . 

Memory Override 

When this one-bit field is TRUE, the MLIP will ignore 
odd-tagged (memory-protected) words in memory during data 
transfer. This field is set to TRUE for I/Os initiated to 
perform memory I/Os for requestors such as PRESENCEBIT and 
SWAPPER. 



Input 



When this one-bit field is TRUE, input 
allowed. 



from the DLP is 



Output 

When this one-bit field is TRUE, 
allowed. 



output to the DLP is 



Output Zeros 

When this one-bit field is TRUE, the MLIP will generate a 
data stream of all O's (zeros) to send to the DLP. This 
feature is used only to perform erase operations on 
magnetic tape DLPs that require data to be sent, to 
determine the length of the erasure. 



Tag Control 

This three-bit field controls the setting and transfer 
tags during I/O operations. 



of 



Word-Oriented Transfer 

When this one-bit field is TRUE, the MLIP interprets the 
MLIP Current I/O Length (Word 11) in units of words, as 
opposed to characters. 

Memory Direction 

When this one-bit field is TRUE and the Input field of the 
MLIP Control Word is TRUE, then the MLIP transfers the 
received data to memory locations of descending order. 



Continue Count at End of Length 

When this one-bit field is TRUE, the MLIP allows the DLP 
to transfer more data than the originally specified I/O 
length (allowing the MLIP Current I/O Length (Word 11) to 
be decremented past 0), but does not store the excess data 
in memory. This field is set to TRUE when the software 



3 b 



PHYSICAL I/O OVERVIEW 

requires information about the actual length of a block, 
read from a variable-record-length device such as tape. 

Ignore Count Error 

When this one-bit field is TRUE, the MLIP will not report 
a Count Error, even if the MLIP Current I/O Length (Word 
11) is not when the I/O nas finished (see "MLIP State 
and Result" below). This field is set to TRUE for some 
I/Os to fixed-record-length devices and for some tape read 
operations (especially when the Continue Count at End of 
Length is TRUE). Ignore Count Error is specifically set 
to FALSE for I/Os for which the length of the data 
transfer .Tiust be exact (for example, for disk., Network. 
Support Processor (NSP), and tape write operations). 

Don't Count 

When this one-bit field is TRUE, the MLIP will not 
increment or decrement the command or unit queue's Active 
Count for this I/O. This feature is used only when 
Initiating a Cancel operation (used only for DLPs that do 
not support a Discontinue operation), because the Cancel 
does not finish normally. 

Ignore Suspend All Queues 

The MLIP nas a bit (MLIP Suspend All Queues field) set to 
unconditionally suspend the command or unit queue when the 
I/O compl'Stes. However, if the Ignore Suspend All Queues 
field is TRUE, the MLIP will not suspend the command or 
unit queu-= when the I/O completes. This feature is used 
only wh*?n initiating Error lOCBs (see "MLIP Error 
Handling" ) . 

Immediate 

When this one-bit field is TRUE, the MLIP will ignore the 
value of the command or unit queue's Active Count and 
Suspended fields when considering initiating the lOCB. 
This field is usually set for MLIP operations (see the 
"MLIP" section), for peripheral status operations (see the 
"Peripheral Status" section), and for retry I/Os. 

Disk. Seek. Optimization 

When this one-bit field is TRUE, the MLIP is allowed to 
reorder "he lOCB with respect to other lOCBs in the unit 
queue. D.Lsk seek, optimization is available only on A 3K 
and A 10 systems. 



37 



PHYSICALIO/MLIP Interface 

Simple Path Selection 

When this one-bit field is TRUE, the MLIP uses the path 
specified in the unit queue. The Path Table Pointer (Word 
9) of the unit queue specifies the path (see "Unit 
Queue"). Simple path selection is available only on A 3K 
and A 10 systems. 

DLP Address Word 

Word 1 contains several fields used by the MLIP to address a 
DLP. For A3, A 9, B 5900, and B 6900 systems, this word 
contains an MLI port number, a Line Expansion Module (LEM) port 
a DLP address within the base (see "Path 
The A 3K and A 10 systems also use the above 
fields and have three additional fields: an MLIP processor ID, 
a Host Return field, and a DLP index. 

Command or Unit Queue Header Pointer 

Word 2 contains a reference to the command queue header for the 
command queue, or the unit queue header for the unit queue, in 
which the lOCB is to be queued. 

lOCB Self Pointer 

Word 3 contains a reference to the lOCB itself. 



number , and 
Specification") 



DLP I/O Command Pointer 

Word 4 contains a reference to the memory area 
command to be sent to the DLP. 



containing the 



DLP I/O Result Pointer 

Word 5 contains a reference to the memory area in which the DLP 
result is to be stored. 

DLP Command/Result Lengths 

Word 6 contains the length of the DLP command to be sent and 
the length of the expected DLP result. For A 3K and A 10 
systems it also contains a Disk. Address field. If the lOCB 
indicates that disk, seek, optimization is to be performed, this 
field contains the 16 most significant bits of the disk, address 
at which the data transfer begins. 

Result Mask 

Word 7 contains a mask, indicating which DLP results are not to 
be considered exceptions for the purpose of reporting DLP 
errors in the MLIP result (see "MLIP State and Result" below). 



Result Queue Head Pointer 

Word 8 contains a reference to the result queue head for the 
result queue Into which this lOCB is to be queued upon 
completion. 
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Next lOCB Llnfc 

Word 9 contains a link to the next lOCB in the command queue or 
result queue for A3, A 9, B 5900, and B 6900 systems. The 
MLIP updates this link as the I/O is being processed. For A 3K 
and A 10 systems this word contains a link to the next lOCB in 
the lOCB queue, unit queue, or result queue. The MCP updates 
the link when queuing lOCBs in the lOCB queue. 

MLIP Current Data Area Pointer 

Word 10 contains a reference to the data area for the data to 
be transferred. It is initialized using the buffer descriptor, 
offset, and length passed to PHYSICALIO by the I/O requestor, 
and is updated by the MLIP as data is transferred. 

MLIP Current I/O Length 

Word 11 contains the length of the data area remaining for data 
transfer. It is initialized to the I/O length passed to 
PHYSICALIO by the I/O requestor and is updated by the MLIP as 
data is transferred. 



MLIP State and Result 

Word 12 is assigned by 
Information for the I/O 
exceptions are reported: 



the MLIP to report the result 
performed. The following types of 



Exception 

This one-bit field is set when any other exception 
are set. 



fields 



Attention 

This one-bit field is set 
0) in the lOCB. 



in the MLIP Control Word (Word 



DLP Error 

This one-bit field is set when the result of masking the 
first 48 bits of the DLP result with the Result Mask (Word 
7) in the lOCB is not 0. 

MLIP/MLI Error 

This one-bit field is set if any of the following one-bit 
exception fields for the MLIP State and Result word are 
set : 



Memory Protect 

Count Error 

Improper lOCB Word (for example, incorrect tag) 

Invalid MLIP Control Field 

MLI Vertical Parity Error 

MLI Longit jidinal Parity Word Error 

Unexpected DLP Status (MLI protocol error) 

Nonpresent DLP 
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DLP Busy 
MLI Time Out 
Invalid MLIP Command 

MLIP/Hardware Error 

This one-bit field is set when an error occurs that must 
be reported through an Error lOCB (see "MLIP Error 
Handling"). 

Completed After Queue Suspended 

This one-bit field is set if the I/O finished when the 
Suspended field in the Queue Control Word of the command 
queue header is TRUE (see "Command Queue"). 

MLIP Not Available 

This one-bit field is available only on A 3K and A 10 
systems and is set if the DLP Address Word (Word 1) of the 
lOCB references an MLIP processor ID that is not 
available. 

I/O Start Time 

The MLIP stores the time of day into Word 13 when the MLIP 
initiates the I/O. 

I/O Finish Time 

The MLIP stores the time of day into Word 14 when the I/O is 
finished. 



Before passing the lOCB to the MLIP, PHYSICALIO ensures that the lOCB 
contains all of the information required for the I/O operation. Some 
information is not required for some types of I/O operations. For 
example, information pertaining to DLPs is not required for operations 
directed to the MLIP itself, and information pertaining to data buffers 
and lengths Is not required for operations that do not involve data 
transfer. Some words in the lOCB are changed as the lOCB is queued, 
initiated, processed, and finished. These changes are described as the 
discussion proceeds through the I/O process. 



See also 

Command Queue 42 

Exception Handling 26 

I/O Finish Interrupt 62 

MLIP 65 

MLIP Error Handling 63 

Path Specification 81 

Peripheral Status 91 

Result Queue 60 

Unit Queue 48 
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CUIO OPERATOR 



The CUIO operator is us?d in A 3, A 9, B 5900, and B 6900 systems and Is 
executed by the MCP to pass the address of an lOCB to the MLIP for 
initiation. The processor executing the CUIO operator verifies that its 
parameter is the address of an lOCB by checking the lOCB Mark, field in 
the MLIP Control Word (Word 0). If the mark is not correct, an Invalid 
Operand interrupt is g'?nerated; if it is correct, the address is passed 
to the MLIP, and the operator completes when the MLIP indicates that it 
has received the address. 



The MLIP also verifies :he lOCB Mark field. If the mark is not correct, 
an Error lOCB is completed (see "MLIP Error Handling"). If the mark is 
correct, the MLIP queue; the referenced lOCB into the command queue 
specified by the Command Queue Header Pointer (Word 2) and determines 
whether or not to initiate the first I/O in that command queue. The I/O 
initiation process involves some changes to the IOCS (described in "lOCB 
Queue") and may require communication with the UIO subsystem (described 
in the "MLIP/UIO Interface" section). 



See also 

MLIP Error Handling 63 

MLIP/UIO Interface 71 
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lOCB QUEUE 



The lOCB queue is used by PHYSICALIO in the A 3K and A 10 systems to 
send lOCBs to the MLIPs. To assure that I/Os are initiated in the 
correct order for single-user devices such as tape drives and printers, 
only one lOCB queue should be created per partition. Each MLIP's I/O 
table contains a pointer to the lOCB queue in the lOCB Queue Head 
Pointer (Word 1) . 



The lOCB queue is composed of the three 
described below. 



words shown in Table 2 and 



Table 2. lOCB Queue 



Word 0: 
Word 1: 
Word 2: 



lOCB 


Queue 


Control 


Word 


lOCB 


Queue 


Head 




lOCB 


Queue 


Tail 





lOCB Queue Control Word 

Word contains the lOCB Qu€>ue Mark. 4 '1001' and a lock. bit. 
The lock bit is used by PHYSICALIO and the MLIP to synchronize 
access to the lOCB queue. 

lOCB Queue Head 

Word 1 contains a reference to the first lOCB in the lOCB 
queue . 



lOCB Queue Tail 

Word 2 contains a reference to the last lOCB in the lOCB queue. 
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COMMAND QUEUE 



A command queue is used In A 3, A 9, B 5900, and B 6900 systems and is a 
link-ed list of lOCBs th-at are to be initiated, usually to the same unit. 
A command queue is controlled by a data structure called a command queue 
header, which is comoosed of the five words shown in Table 3 and 
described below. 



Table 3. Command Queue 



Word 0: 
Word 1: 
Word 2: 
Word 3: 
Word 4: 



Qu.?ue Control Word 
He.ad lOCB Link 



Tall lOCB Link. 

Horizontal Queue Head Pointer 

Hofizontal Queue Link. 



Queue Control Word 

Word contains several fields that provide parameter 
Information es:ablished by the MCP and queue status information 
maintained by :he MLIP. 

Command Queue Header Mark. 

This 16-bLt field contains the code 4'IOCC', which marks 
the word as the first word of a command queue header. 

Inactive Count 

This elgh:-bit field contains the number of lOCBs that are 
currently queued but have not been initiated. 

Active Count 

This eigh;-bit field contains the number of lOCBs that 
have been initiated out of the queue and are still in 
progress. 

Active Limit 

This eigh-:-blt field is Initialized by the MCP to the 
maximum number of lOCBs from this queue that may be 
simultaneously in progress. The MLIP will not Initiate 
any lOCBs from the queue if the Active Count is greater 
than or equal to the Active Limit, unless the lOCB being 
considered for initiation has the Immediate field in the 
MLIP Control Word (Word 0) set to TRUE (see "lOCB"). 
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Suspended 

This one-bit field is set to TRUE under the following 
conditions: 

1. When an lOCB initiated out of the queue completes 
with the Exception field in the MLIP State and Result 
(Word 12) set to TRUE 

2. When an lOCB initiated out of the queue is completed 
while the MLIP Suspend All Queues field is TRUE and 
the Ignore Suspend All Queues field in the IOCS' s 
MLIP Control Word (Word 0) is FALSE 

3. When the MCP requests the MLIP to deactivate the 
queue (see "MLIP") 

If the command queue's Suspended field is TRUE, the MLIP 
will initiate an lOCB out of the queue only if the lOCB 
being considered for initiation has the Immediate field in 
the MLIP Control Word (Word 0) set to TRUE. 

Waiting 

This one-bit field is set to TRUE by the MLIP when the 
command queue is linked into a horizontal queue (see 
"Horizontal Queue" ) . 

Horizontal Queue Present 

This one-bit field is set to TRUE by the MCP to indicate 
that the MLIP can link, this queue into the horizontal 
queue specified in the Horizontal Queue Head Pointer field 
(see below) when necessary. 

Head lOCB Link 

Word 1 contains a reference to the first (Inactive) lOCB in the 
command queue. It is updated whenever an lOCB is unlinked from 
the queue and whenever a new lOCB is inserted at the head of 
the queue because the Queue at Head field in the MLIP Control 
Word (Word 0) of the lOCB was TRUE. 

Tail IOCS Link 

Word 2 contains a reference to the last (inactive) lOCB in the 
command queue. It is updated whenever a new lOCB is linked at 
the end of the queue and whenever the last lOCB is initiated 
out of the queue. 

Horizontal Queue Head Pointer 

Word 3 is initialized by the MCP and contains a reference to 
the head of the horizontal queue into which this command queue 
is to be linked if necessary (see "Horizontal Queue"). 
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Horizontal Queue Lin:c 

Word 4 is used oy the MLIP to link the command queue into a 
horizontal queue when necessary (see "Horizontal Queue"). 



For most devices, PHYSICALIO allocates one command queue per unit per 
path to that unit. For Operator Display Terminals (ODTs), there are two 
command queues per unit: one for writes and one for reads and test/wait 
for transmit operations. For Network. Support Processors (NSPs), three 
command queues for each :>ISP are allocated (see the "Data Communications" 
section) . 



When an I/O is linked iito a command queue, the MLIP updates the 
Inactive Count field of :he Queue Control Word (Word 0) to indicate that 
another lOCB has been queued. If the lOCB was queued at the head of the 
command queue, the Head lOCB Link (Word 1) in the command queue header 
and the Next lOCB Link (Vord 9) of the lOCB following the new lOCB are 
updated: if the lOCB -tfas queued at the tail of the command queue, the 
Tail lOCB Link (Word 2) of the command queue header and the Next lOCB 
Link (Word 9) of the lOCB preceding the new lOCB are updated. Figure 5 
shows three lOCBs linked into command queue header "A". 
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Command Queue Header "A" 



lOCB 1 



— > 



CQ Header 



Next Link 



Queue Control Word 



Head lOCB Link 
Tail lOCB Link 



HQ Head Pointer 
HQ Link 



-+< 






lOCB 2 



— > 



CQ Header 



Next Link 



lOCB 3 



— > 



CQ Header 



Next=NULL 



<-) — 



CQ - Command queue 
HQ = Horizontal queue 



Figure 5. Multiple lOCBs Linked to a Command Queue 



The command queue header links are static throughout the processing of 
the lOCB and are not shown in subsequent figures. 



The MLIP begins processing a particular command queue under any of the 
following circumstances; 

1. When PHYSICALIO initiates an lOCB to that queue. 

2. When an I/O operation for an lOCB in that queue is complete 
(for example, when an activate queue MLIP operation, simply by 
ending, causes that command queue to be processed by the MLIP). 

3. When the command queue is reached by following the links in a 
horizontal queue (see "Horizontal Queue"). 
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Whenever the MLIP is processing a particular command queue, it attempts 
to initiate as many lOCBs as possible from that queue. The number of 
lOCBs that can be initiated depends on factors such as whether or not 

The command queue's Active Count is less than the command queue's 
Active Limit. 

- The Suspended field is TRUE. 

- The IOCS' s Immediate field is TRUE. 

The command queue is already queued in a horizontal queue waiting 
for the DLP (see "Horizontal Queue"). 

When an lOCB is initiated, the lOCB's Next lOCB Link (Word 9) is set to 
1 and the lOCB is unlinlced from the command queue, as shown in Figure 6. 



lOCB 1 



CQ Header 



Next=l 



Command Queue Header "A" 




Queue 


Control Word 


Head 


lOCB 


Link. 


Tail 


lOCB 


Link. 


HQ Head Pointer 


HQ Li 


nk 





lOCB 2 



— > 



CQ Header 



Next Link 



lOCB 3 



— > 



CQ Header 



Next=NULL 



< — 



CQ = Command queue 
HQ = Horizontal queue 



Figure 6. Init;.ated lOCB Unlinked from a Command Queue 
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At the time the I/O Is initiated, the MLIP sets the I/O Start Time (Word 
13) of the lOCB to the time of day. 



For I/O operations that involve data transfer, the data is transferred 
in bursts when the DLP indicates that it is ready to receive or transmit 
data (see the "MLIP/UIO Interface" section). As data is sent to or 
received from the DLP, the MLIP adjusts the MLIP Current Data Area 
Pointer (Word 10) and the MLIP Current I/O Length (Word 11) of the lOCB 
to correspond to the location and amount of data left to be transmitted. 



See also 

Data Communications 95 

Horizontal Queue 58 

lOCB 33 

MLIP/UIO Interface 71 
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UNIT QUEUE 



A unit queue is used in A 3K and A 10 systems and is a linked list of 
lOCBs that are to be initiated, usually to the same unit. A unit queue 
is controlled by a data structure called a unit queue header, which is 
composed of the 11 words shown in Table 4 and described below. 

Table 4. Unit Queue 



Word 


0: 1 


Word 


1: 1 


Word 


2: 1 


Word 


3: i 


Word 


4: 1 


Word 


5: 1 


Word 


6: 1 


Word 


7: 1 


Word 


8: 1 


Word 


9: 1 


Word 


10: 1 



Queue Control Word 
Head lOCB Link. 



Tail lOCB Link 

Horizontal Queue Head Pointer 

Dynamic Unit Queue Link. 

Last lOCB Initiated 

Spare 

I/O Optimization Word 1 

I/O Optimization Word 2 

Patn Table Pointer 

Unit-Related Path Information 



Queue Control Word 

Word contains fields that provide parameter information 
established by the MCP and queue status information maintained 
by the MLIP. 

Unit Queue Header Mark. 

This 16-bi : field contains the code 4'IOCC', which marks 
the word as the first word of a unit queue header. 

Inactive Count 

This eight-bit field contains the number of lOCBs that are 
currently queued but have not been initiated. 

Active count 

This eight-bit field contains the number of lOCBs that 
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have been initiated out of the queue and are still in 
progress. 

Active Limit 

This eight-bit field is initialized by the MCP to the 
maximum number of lOCBs from this queue that can be 
simultaneously in progress. The MLIP will not initiate 
any lOCBs from the queue if the Active Count is greater 
than or equal to the Active Limit, unless the lOCB being 
considered for initiation has the Immediate field in the 
MLIP Control Word (Word 0) set to TRUE (see "lOCB"). 

Suspended 

This one-bit field is set to TRUE under the following 
conditions: 

1. When an lOCB initiated out of the queue is completed 
with the Exception field in the MLIP State and Result 
(Word 12) set to TRUE 

2. When an lOCB Initiated out of the queue is completed 
while the MLIP Suspend All Queues field is TRUE and 
the Ignore Suspend All Queues field in the lOCB's 
MLIP Control Word (Word 0) is FALSE 

3. When the MCP requests the MLIP to deactivate the 
queue (see the "MLIP" section) 

If the unit queue's Suspended field is TRUE, the MLIP will 
initiate an lOCB out of the queue only if the lOCB being 
considered for initiation has the Immediate field in the 
MLIP Control Word (Word 0) set to TRUE. 

Waiting 

This one-bit field is set to TRUE by the MLIP when the 
unit queue is linked into a horizontal queue (see 
"Horizontal Queue"). 

Horizontal Queue Present 

This one-bit field is set to TRUE by the MCP to indicate 
that the MLIP can link, this queue into the horizontal 
queue specified by the Horizontal Queue Head Pointer field 
(see below) when necessary. 

Path Selected 

This one-bit field tells whether or not the MLIP has 
executed the Path Selection algorithm for the top lOCB in 
the unit queue. 
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Connection in Progress 

If this one-bit field is set, an MLIP has initiated a Poll 
Test to the DLP specified by the Data Link. Processor 
Address Word (DLPAW) of the top IOCS in the unit queue. 



Waiting :in MLIF Queue 

If this one-bit field is set, the unit queue is 
dynamically linked in an MLIP queue. 



currently 



Lock Bit 

This one-bit field is used by 
access to the unit queue. 



the MLIPs to synchronize 



Head IOCS Link 

Word 1 contains a reference to the first (inactive) lOCB in the 
unit queue. It is updated whenever an lOCB is unlinked from 
the queue and whenever a new lOCB is inserted at the head of 
the queue because the Queue at Head field in the MLIP Control 
Word (Word 0) of the lOCB was TRUE. 

Tail lOCB Link 

Word 2 contains a reference to the last (inactive) lOCB in the 
unit queue. It is updated whenever a new lOCB is linked at the 
end of the queue and whenever the last lOCB is initiated out of 
the queue. 

Horizontal Queue Head Pointer 

Word 3 is initialized by the MOP and contains a reference to 
the head of the horizontal queue into which this unit queue is 
to be linked if necessary (see "Horizontal Queues"). 

Dynamic Unit Queue Link 

Word 4 is used by the MLIP to dynamically link unit queues in 
horizontal queues and MLIP queues. 

Last lOCB Initiated 

Word 5 references the last non-MLIP command lOCB initiated from 
the unit queue. 

Spare 

word b is reserved for future expansion. 

I/O Optimization Word 1 

Word 7 contains information that is used to optimize the 
throughput of disk I/Os. 



Physical Integrity Check 

This one-bit field determines whether the MLIP guarantees 
that overlapping I/Os are not reordered with respect to 
one another. 
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Maximum lOCBs to Examine 

This six-bit field determines the maximum number of lOCBs 
that are examined by the Disk Seek. Optimization algorithm. 

Bypass Limit 

This four-bit field contains the maximum number of times 
that the top lOCB can be bypassed in favor of another lOCB 
in the unit queue at lOCB initiation time. 

Bypass Count 

This four-bit field contains the number of times that the 
top lOCB has been passed over in favor of another lOCB in 
the unit queue at lOCB initiation time. 

Disk Address 

This 16-bit field contains the value from the Disk Address 
field in the DLP Command/Result Lengths (Word 6) in the 
lOCB selected as the best lOCB by the Disk Seek 
Optimization algorithm. 

I/O Optimization Word 2 

Word 8 contains information that is used to optimize the 
throughput of disk I/Os. If the Physical Integrity Check field 
of I/O Optimization Word 1 is set, PHYSICALIO must initialize 
the Cylinder Size and Minimum Difference fields. 

Cylinder Size 

This 28-bit field contains the size of a disk cylinder in 
bytes . 

Minimum Difference 

This 20-bit field contains the information to determine if 
I/Os overlap. 

Path Table Pointer 

Word 9 contains the address of the DLP for simple path 
selection. 

Unit-Related Path Information 

Word 10 contains unit-related path information and the 
following field. 

Unit DLP Mask 

This field specifies the DLPs through which there is a 
ready physical path to the unit. 



PHYSICALIO allocates one unit queue per unit, regardless of the number 
of paths to the unit. The name "unit queue" implies that all I/Os for 
one unit are sent to a single queue. 
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When an I/O is linked into a unit queue, the MLIP updates the Inactive 
Count field of the Queue Control Word (Word 0) to indicate that another 
lOCB has been queued. If the lOCB was queued at the head of the unit 
queue, the Head lOCB Link. (Word 1) in the unit queue header and the Next 
lOCB Link (Word 9) of the lOCB following the new lOCB are updated; if 
the lOCB was queued at the tail of the unit queue, the Tail lOCB Link 
(Word 2) of the unit queue header and the Next lOCB Link (Word 9) of the 
lOCB preceding the new lOCB are updated. Figure 7 shows three lOCBs 
linked into unit queue header "A": 



Unit Queue Header "A' 



Queue Control Word 


Head lOCB Link 


Tail IOCS Link 


HQ Head Pointer 


Dynamic UQ Link 



I 1 

I Unit-Related Path Info I 



< f <- 



lOCB 1 



lOCB 2 



I 
lOCB 3 I 



— > 



UQ Header 



Next Link 



UQ Header 



Next Link 



UQ Header 



Next=NULL 



<-)- 



HQ = Horizontal queue 
UQ = Unit queue 



Figure 7. Multiple lOCBs linked to a Unit Queue 
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The unit queue header links are static throughout the processing of the 
lOCB and are not shown in subsequent figures. 



The MLIP begins processing a particular unit queue under any of the 
following circumstances: 

1. When PHYSICALIO initiates an lOCB to that queue 

2. When an I/O operation for an lOCB in that queue is complete 
(for example, when an Activate Queue MLIP operation, simply by 
ending, causes that unit queue to be processed by the MLIP) 

3. When the unit queue is reached by following the links in a 
horizontal queue (see "Horizontal Queue") 



Whenever the MLIP is processing a particular unit queue, it attempts to 
initiate as many lOCBs as possible from that queue. The number that can 
be Initiated depends on factors such as whether or not the unit queue's 
Active Count is less than the unit queue's Active Limit, whether or not 
the Suspended field is TRUE, whether or not the lOCB's Immediate field 
is TRUE, and whether or not the unit queue is already queued in a 
horizontal queue waiting for the DLP (see "Horizontal Queue"). 
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When an lOCB is initiated, the lOCB's Next lOCB Link. (Word 9) is set to 
1 and the lOCB is unlink.ed from the unit queue, as shown in Figure 8. 



IOCS 1 



UQ Header 



Next=l 



Unit Queue Header "A" 
Queue Control Word 
Head lOCB Link 
Tail lOCB Link 



HQ Head Pointer 
Dynamic UQ Link 

I 1 

I Unit-Related Path Inf o | 
I I 



lOCB 2 



lOCB 3 



UQ Header 



Next Link 



--> 



UQ Header 



Next^NULL 



< — 



HQ = Horizontal queue 
UQ = Unit queue 



Figure 8. Ini:iated IOCS Unlinked from a Unit Queue 



At the time the I/O is initiated, the MLIP sets the I/O Start Time (Word 
13) of the lOCB to the time of day. 
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For I/O operations that involve data transfer, the data is transferred 
in bursts when the DLP indicates that it is ready to receive or transmit 
data (see the "MLIP/UIO Interface"section) . As data is sent to or 
received from the DLP, the MLIP adjusts the MLIP Current Data Area 
Pointer and the MLIP Current I/O Length (Words 10 and 11) of the lOCB to 
correspond to the location and amount of data left to be transmitted. 



See also 

Data Communications 95 

Horizontal Queue 58 

lOCB 33 

MLIP/UIO Interface 71 
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MLIP I/O TABLE 



The MLIP I/O table is used by the MLIP in the A 3K and A 10 systems. 
The MCP sets up an MLIP I/O Table for each MLIP in the partition. Once 
the table has been set up, the MCP is not allowed to update or access 
any word in the table except through an MLIP I/O operation. 



The MLIP I/O table, shown in Table 5 below, contains an lOCB queue head 
pointer, the MLIP queue, destination sets, and a scratch area. 
Descriptions of these words and fields are given below. 



Table 5. MLIP I/O Table 



Word 0: 
Word 1: 
Word 2: 
Word 3: 
Word 4: 
Word 5: 
Word 6: 
Word 7: 



MLIP 


I/O Table Control Word 








lOCB 


Queue Head 


Pointer 










MLIP 


Queue Control Word 










MLIP 


Qu9ue Head 


Unit Queue 


Link 


Data 


Descr] 


.ptor 


MLIP 


Queue Tail 


Unit Queue 


Link. 


Data 


Descr] 


.ptor 


EMP Destination 


Set 










MLIP 


Destination Set 










MLIP 


Scratch Area Word 











Word 16: | MLIP Scratch Area Word 9 



MLIP I/O Table Control Word 

Word consists of the MLIP I/O table control mark, field 
containing the code 4'IOCO'. 



IOCS Queue Head Pointer 

Word 1 contains a pointer to the lOCB queue. The MCP 
Initializes the lOCB queue head pointer, which cannot be 
altered by the MLIP or the MCP. 
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MLIP Queue Control Word 

Word 2 consists of a MLIP queue mark field, an undefined area, 
and a lock bit. 

MLIP Queue Mark. 

The MLIP Queue Mark field contains the code 4'10C2'. 

Lock Bit 

MLIPs use the lock bit to synchronize access to the MLIP 
queue. 

MLIP Queue Head Unit Queue Link Data Descriptor 

Word 3 contains the pointer to the first unit queue in the MLIP 
queue. PHYSICALIO initializes this word to 0. 

MLIP Queue Tail Unit Queue Link Data Descriptor 

Word 4 contains the pointer to the last unit queue in the MLIP 
queue. PHYSICALIO initializes this word to 0. 

EMP Destination Set 

Word 5 contains the destination set of EMPs that are signaled 

for I/O Finish. The EMP destination set is a bit mask where 
bit 1 corresponds to EMP #1, bit 2 corresponds to EMP #2, and 

so on. The MCP sets a bit for each running EMP in the 

partition. If the partition configuration changes, the MCP 
updates the word by using an MLIP command. 

MLIP Destination Set 

Word 6 contains the destination set of MLIPs. An MLIP can 

communicate only to MLIPs specified in this word. The MLIP 

destination set is a bit mask where bit 1 corresponds to MLIP 
#1, bit 2 corresponds to MLIP #2, and so on. The MCP sets a 

bit for each running MLIP in the partition. If the partition 

configuration changes, the MCP updates the word by using the 
MLIP command. 

MLIP Scratch Area Word through Word 9 

The MLIP uses this as a scratch area that consists of 10 words 
(Word through Word 9). The MCP initializes the scratch area 
to 0. 
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HORIZONTAL QUEUE 



A horizontal queue is a mechanism for queuing command queues or unit 
queues when the DLP path to the unit is busy. The A 3, A 9, B 5900, and 
B 6900 systems use the command queue, and the A 3K and A 10 systems use 
the unit queue, to initiate the MLIP. The term "command/unit queue" is 
used to refer to the queue for its respective computer system. 



During system Initialization, PHYSICALIO builds a horizontal queue array 
containing a one-word horizontal queue header for each of several 
horizontal queues (Word of the array contains a Queue Length field and 
the code 4'IOCE' as a Horizontal Queue Mark). In general, PHYSICALIO 
assigns a horizontal quoue header for each DLP that can accept multiple 
I/O requests but might be momentarily unable to accept a command because 
it is actively processing a previous command. 



When the MLIP attempts "O initiate an I/O to a DLP that is busy, the 
MLIP checks the Horizontal Queue Present field in the Queue Control Word 
(Word 0) in the command/unit queue header to determine whether or not 
this command/unit queue is eligible to be queued into a horizontal 
queue. If so, the MLIP queues the command/unit queue in the horizontal 
queue specified by the Horizontal Queue Head Pointer (Word 3) in the 
command/unit queue header. If this command/unit queue is the first in 
the horizontal queue, "he Horizontal Queue Head is set to point to this 
command/unit queue. If it is not the first (that is, if there is 
already at least one command/unit queue in the same horizontal queue), 
this command/unit queue is linked to the tail of the horizontal queue. 
In A 3, A 9, B 5900, and B 6900 systems, the Horizontal Queue Link. (Word 
4) in the command queue header of the command queue (previously at the 
tail of the horizontal queue) is set to point to this command queue. In 
A 3K and A 10 systems, -:he Dynamic Unit Queue Link (Word 4) in the unit 
queue header of the uni-: queue is set to point to this unit queue. 



In order to support uni" queues, the MLIPs must share the horizontal 
queue array. This sharing is done by having each MLIP lock the entire 
horizontal queue array prior to queuing or unqueuing unit queues. Word 
of the Horizontal Queue Array is used as the lock word. 



59 

PHYSICALIO/MLIP Interface 
Figure 9 shows two command queues linked into the same horizontal queue. 

Horizontal Queue Array 



I Header 
I Word 



I I HQ Head! 
I I "Z" 1 



Command Queue Header "A" 
I 

->l Queue Control Word | 
1 

Head lOCB Link. | 
1 

Tall lOCB Link, | 
1 

HQ Head Pointer — >+<- 
1 

HQ Link, > 



Command Queue Header "B" 



Queue Control Word 



Head lOCB Link 
Tail lOCB Link 



HQ Head Pointer 
HQ Link=NULL 



HQ = Horizontal queue 
Figure 9. Multiple Command Queues Linked to a Horizontal Queue Array 

When the MLIP finishes processing a command/unit queue (that is, when it 
cannot Initiate any more commands from that command/unit queue), It 
checks the horizontal queue referenced by the command/unit queue header 
to see if other command/unit queues are waiting. If so, the MLIP 
unlinks and begins processing the first command/unit queue in the 
horizontal queue. In this fashion, the MLIP traverses the entire 
horizontal queue. 
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RESULT QUEUE 



Result queues are lists of completed lOCBs. During system 
initialization, PHYSICALIO builds a result queue array for each 
processor in A 3, A 9, B 5900, and B 6900 systems. In A 3K and A 10 
systems, only one result queue array is initialized. A result queue 
array contains a header word (which includes a Queue Length field and 
the code 4'IOCF' as the Result Queue Mark.) and a one-word Result Queue 
Head for each of several result queues. The exact number of result 
queues is determined by the number of classes of results that are to be 
queued separately. Typically, PHYSICALIO establishes seven result 
queues, one for each of ihe following result classes: 

1. Normal I/Os 

2. Internal PHYSICALIO ("kernel") I/Os 

3. Peripheral status I/Os 

4. Error lOCB I/Os 

5. Datacomm I/Os 

6. Intersystem con:rol I/Os 

7. Disfc and pack I/Os 



Before passing an lOCB t' 
Queue Head Pointer (Wor- 
to be queued into on com; 
MLIP sets the I/O Finis 
stores its MLIP result i 
stores the DLP result 
Pointer (Word 5). The m: 
result queue specified ( 
and decides whether or n 
Finish Interrupt"). 



3 the MLIP, the MCP must indicate, in the Result 
i 8) of the lOCB, which result queue the lOCB is 
pletion. When the operation is complete, the 
1 Time (Word 14) of the lOCB to the time of day, 
ito the MLIP State and Result (Word 12), and 
in the location specified by the DLP I/O Result 
:l,IP then links the lOCB at the head of the 
that is, the result queue is last-in, first-out) 
3t to cause an I/O Finish interrupt (see "I/O 



Because several ML IPs can update the same result queue, the Next lOCB 
Link. (Word 9) cf the first lOCB is checked before the result queue is 
updated. The MCP checks the Next lOCB Link (Word 9) for its value. If 
the value is 1, the lOCB is not processed. 



In the situation depicted by Figure 10, lOCBs 1 and 2 of command queue 
"A" have completed, lOCB 1 first; both are linked into result queue "L." 
Command queue header "A" is queued in horizontal queue "Z," waiting for 
the DLP to become available so that lOCB 3 can be initiated. When 
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lOCB 3 completes, It will be linked into result queue "M." In A 3K and 
A 10 systems, a unit queue can be used in place of the command queue in 
this example. 



Command 


Queue Header 


"A" 


Queue Control Word 


Head lOCB Link 


Tail lOCB Link 


HQ Head 


Pointer— >"Z" 




HQ Link. 


— > CQ Header 


"B" 



lOCB 1 



lOCB 2 



CQ Header "A" 
RQ Head "L" 



Next=NULL 



< — 



CQ Header "A" 



RQ Head "L" 
Next Link 



<~ 



lOCB 3 



CQ Header "A" 



RQ Head "M" 
Next^NULL 



I Header I |RQ Head IRQ Head 
I Word I |"L" I "M" 



I- 



Result Queue Array 



CQ = Command queue 
HQ = Horizontal queue 
RQ = Result qu€?ue 



Figure 10. Multiple lOCBs Linked to a Result Queue Array 
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I/O FINISH INTERRUPT 



When the MLIP has finished processing an lOCB and the lOCB has been 
linked into the appropriate result queue, the MLIP must decide whether 
or not to cause an I/O Finish interrupt to notify the processor. The 
MLIP will cause an ::/0 Finish interrupt for any one of the following 
conditions : 

1. The MCP has requested an interrupt by setting the Cause I/O 
Finish Interrupt field in the MLIP Control Word (Word 0) of the 
completing lOCIi. 

2. The Exception field in the MLIP State and Result (Word 12) of 
the completing lOCB is TRUE. 

3. The command/un;.t queue of the finishing lOCB is empty. 
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MLIP ERROR HANDLING 



In addition to lOCBs that the MCP allocates to perform I/Os, a small 
number of lOCBs are allocated to provide the MLIP with a mechanism to 
report errors that are not relevant to the lOCB currently in progress, 
or for which there is too much information to be reported in the lOCB. 



These "Error lOCBs" are initiated during system initialization, but are 
not completed until they are needed to report one of the following 
errors: 

- An invalid queue structure (for example, bad queue mark.). 
An invalid queue reference. 

- A bad descriptor link, received from a DLP (see the "MLIP/UIO 
Interface" section). 

A memory error detected by the MLIP. 



Error lOCBs have their own command/unit queue and result queue. Because 
it is important that the Error lOCB command/unit queue not be suspended, 
the MCP and the MLIP take special precautions when handling Error lOCBs. 



In order that the Exception field does not get set to TRUE, the 
following must happen: the MCP must issue all Error lOCBs with the 
Attention field set to FALSE; the MLIP must not set the DLP Error, 
MLIP/MLI Error, MLIP/Hardware Error, or Completed After Queue Suspended 
fields to TRUE. In order that the queue does not get suspended because 
the MLIP Suspend All Queues field is TRUE, the MCP must issue all Error 
lOCBs with the Ignore Suspend All Queues field set to TRUE. 



The MCP issues all Error lOCBs with the Cause I/O Finish interrupt field 
set to TRUE. This action is required because the MLIP is not permitted 
to set any exception fields, and there is no other way for an Interrupt 
to be generated. 



See also 

lOCB 33 

MLIP/UIO Interface 71 
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The Message-Level Interface Processor (MLIP) is a hardware module with 
the following purposes: 

- To accept I/O operations from the Master Control Program (MCP). 

To queue the I/O operations. 

To route the I/O operations to their destination Data Link. 
Processors (DLPs). 

- To handle the Message-Level Interface (MLI) dialog with the DLP. 

- To return the result information to the MCP. 



Many of these functions are described in other sections of this manual, 
particularly in the "PHYSICALIO/MLIP Interface" section and the 
"MLIP/UIO Interface" section. 



MLIP COMMANDS 



The MLIP also performs operations itself. These functions are, for the 
most part, related to queue management and DLP configuration management 
and, with two exceptions, do not involve communication with the 
Universal I/O (UIO) subsystem. 



The MCP requests MLIP operations by setting the MLIP/DLP Command field 
in the MLIP Control Word (Word 0) of an Input/Output Control Block 
(lOCB) to TRUE (indicating MLIP command) and storing, in the first word 
pointed to by the DLP I/O Command Pointer (Word 4) in the lOCB, a code 
indicating a command. The following commands are available on all 
systems that support the MLIP I/O subsystem: 



Walt for Error 



This command indicates to the MLIP that the lOCB is to be used as an 
Error lOCB (see "MLIP Error Handling"). 
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Discontinue Error IOCS 



This command discontinues the currently active Error lOCB, if any. If 
there is no Error IDCB currently active, the MLIP will indicate that 
there is no Error lOCB to discontinue. This operation is used when 
changing software environments, such as when entering and exiting 
TAPEDUMP, to remove all outstanding Error lOCBs. 



Set the Suspend All Queues Flag 



This command sets the MLIP Suspend All Queues field, which suspends any 
active command/unit queues so that no more I/Os can be initiated (see 
"Command Queue" and "Unit Queue"). This command is issued by the MCP 
through the lOFAUCET procedure. The purpose of the command is to 
prevent I/Os from being initiated during a memory dump. 



Reset the Suspend All Q ueues Flag 



This command resets the MLIP Suspend All Queues field, 



Activate Queue 



This command resets the Suspended field in the Queue Control Word (Word 
0) of the comiriand/unit queue specified by the Command or Unit Queue 
Header Pointer (Word 2) in the lOCB, and to start processing the queue. 
This command is issued by the MCP to restart a command/unit queue after 
the exception condition that caused the queue to be suspended has been 
handled appropriately. 



Deactivate Queue 



This command sets the Saspended field in the Queue Control Word (Word 0) 
of the command/unit queue specified by the Command or Unit Queue Header 
Pointer (Word 2) in the lOCB. This command suspends the command/unit 
queue before TEST/WAIT operations and before operations that may alter 
the queue structure, such as BLASTUNIT, PATHRES, and UNITMOVER. 



67 



MLIP 



Return Queue 



This command returns the lOCBs queued in the command/unit queue 
specified by the Command or Unit Queue Header Pointer (Word 2). The 
MLIP returns the queue by copying the Head lOCB Link (Word 1) from the 
Command Queue Header into the first word pointed to by the DLP I/O 
Result Pointer (Word 5) and by setting the Head lOCB Link (Word 1), Tall 
lOCB Link (Word 2), and Inactive Count field of the Queue Control Word 
(Word 0) to 0. The MLIP will not remove the command/unit queue from the 
horizontal queue if it is currently linked. This command is issued by 
BLASTUNIT, for example, when it must alter the structure of the 
co:mmand/unit queue. 



Read MLIP Status 



This command returns one word of status information in the first word of 
the area pointed to by the DLP I/O Result Pointer (Word 5) in the lOCB. 
This status information includes the system type, the MLIP firmware 
revision, the Host Return field (see "Host Identification"), and a bit 
vector identifying the MLI ports that are present. This information is 
requested by the software during peripheral initialization. On A 3K and 
A 10 systems, the MLIP also returns information in bit 16 of the DLP I/O 
Result Pointer (Word 5) as to whether or not disk seek optimization has 
been implemented. 



Read DLP Status 



This command connects the MLIP to the DLP specified in the DLP Address 
Word (Word 1) of the lOCB and reads its status, which is returned in the 
MLIP State and Result (Word 12) of the lOCB. 



Clear DLP 



This command issues an "MLI selective clear" command to the DLP 
specified in the DLP Address Word (Word 1). This operation is used by 
lOFAUCET to clear TEST/WAIT operations when beginning a nonfatal dump 
and by BLASTUNIT when it must ensure that the DLP is in a known state. 
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General Clear 

This command issues an "MLIP master clear" command to all MLI ports. 
This command is issued by lOFAUCET when beginning a fatal dump, and by 
the soft Halt/Load procedure "FAKEHALTLOAD" to simulate the action of a 
Halt/Load. 

MLIP COMMANDS AVAILABLE ON A 3K AND A IQ SYSTEMS 



The following are additional MLIP commands available on the A 3K and 
A 10 systems. 



Return Active lOCB 



This cortimand returns the? active count of the unit queue and Last lOCB 

Initiated (Word 5) of the unit queue to the first and second words 

pointed to by the DLP 1/0 Result Pointer (Word 5) of the lOCB. This 
command is use^d by lODISASTER when handling hung DLPs. 



Set I/O Table EMPDS 



This command updates the EMP Destination Set (EMPDS) (Word 5) of the 
MLIP I/O table. The HCP uses this command after system initialization 
to update the destination set with all of the running E-Mode processors 
(EMPs). 



Set I/O Table MLIPDS 



This command updates the MLIP Destination Set (MLIPDS) (Word 6) of the 
MLIP I/O table. lOFAUCET uses this operator to update the MLIP I/O 
table with a mask, of the running MLIPs during a memory dump. 



Set Unit Queue Path Word 



This command stores the second word pointed to by DLP I/O Command 
Pointer (Word 4) of the lOCB in the Path Table Pointer (Word 9) of the 
unit queue. The MCP uses this operation whenever a path has been 
selected for a unit. 
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Set Unit Queue I/O Optimization Word 2 



This command stores the second word pointed to by DLP I/O Command 
Pointer (Word 4) of the lOCB in the I/O Optimization Word 2 (Word 8) of 
the unit queue. This operation is used by the MCP to maintain data 
necessary for the MLIP to perform disk seek, optimization. 



Decrement Unit Active Limit 



This command decrements the active limit field of the Queue Control Word 
(Word 0) of the unit queue. This operation is used by the MCP when 
maintenance tests are being run. 



Increment Unit Active Limit 



This command increments the active limit field of the Queue Control Word 
(Word 0) of the unit queue. This operation is used by the MCP when 
maintenance tests are being run. 



See also 

Command Queue 42 

Host Identification 73 

MLIP Error Handling 63 

Unit Queue 48 
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The Message-Level Interface Processor (MLIP) communicates with the 
Universal I/O (UIO) subsystem through the Message-Level Interface (MLI), 
a protocol-driven Interface that allows the MLIP and the Data Link 
Processors (DLPs) to process independently between data transfer bursts. 
When the MLIP has an I/O operation to transfer to a particular DLP, it 
connects to the DLP and transfers the DLP command and a "descriptor 
link" to the DLP. The descriptor link contains two items: 

1. The Host Return field, required for the return routing of 
information from the DLP to the MLIP (see "Host 
Identification" ) . 

2. A tag that uniquely identifies a particular I/O operation. 



After the DLP command and descriptor link have been transferred, the 
MLIP can disconnect and perform other operations. 



When a DLP is ready to transfer data, it reconnects to the MLIP and 
transfers the descriptor link for the I/O operation requiring the data 
transfer. The MLIP uses this descriptor link to find the appropriate 
Input/Output Control Block (lOCB) and reconstructs its state by 
accessing the intermediate results it previously stored in the lOCB. 
One or more blocks of data are then transferred, and the MLIP 
disconnects. 



When the DLP has finished the operation, it reconnects to the MLIP and 
transfers both the descriptor link and the DLP result descriptor for the 
completed operation. It then drops the connection, and the MLIP 
finishes processing the lOCB. 



See also 

Host Identification 73 
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UIO SUBSYSTEM 



To determine the configuration of the I/O subsystem, PHYSICALIO must be 
able to uniquely identify every base, Data Link, Processor (DLP), and 
unit in the subsystem. To initiate an I/O to a specific unit, 
PHYSICALIO must be able to select and specify a path to that unit. 
Similarly, to return Information to the system, the I/O subsystem must 
be able to uniquely identify each host. 



This section describes the rules and conventions that must be followed 
to establish a valid Universal I/O (UIO) subsystem configuration. 



HOST IDENTIFICATION 



From the UIO subsystem's point of view, a "host" is any system component 
that communicates with a base on a Message-Level Interface (MLI). A 
host can be an A 3 , A 3K, A 9 , A 10, B 5900, or B 6900 processor; a 
Network Support Processor (NSP); or a B 6900 maintenance processor. 



Each host connecting to a base has an identification number, called a 
Host Return field, that is used by the base to uniquely identify the 
host. The Host Return field must be in the range through 7. The 
B 5900 and B 6900 processors generate Host Return fields that correspond 
to their processor IDs and, thus, are numbered from 1 through 4. The 
B 6900 maintenance processors use a Host Return field of 0, leaving the 
range 5 through 7 available for NSPs. 



For the A 3K and A 10 systems, the Host Return field corresponds to the 
MLIP number (1 through 7). 



A host connects to a base through a distribution card (DC), which is 
identified with a number that matches the Host Return field of the host 
it is connected to. There can be up to six DCs in one base, allowing up 
to six hosts to connect to the same base. Hosts that connect to DCs 
within the same base must have unique Host Return fields, but hosts that 
do not share bases need not have unique Host Return fields. A 
configuration that includes nonunique Host Return fields is illustrated 
in Figure 11, which shows two NSPs (both numbered 6) that do not connect 
to the same base. 
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! 
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-MLI— I I PSM 

LSP 




I Port I Port I Port I Port 

I I 
MLI MLI 



DC 2 
DC 6 
BCC 
PSM 
NSP 6 



— MLI- 
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BCC = Base control card MLIP 

DC = Distribution card NSP 

LSP = Line Support Processor PSM 

MLI = Message-Level Interface 



Message-level Interface Processor 
Network Support Processor 
Path Selection Module 



Figure 11. UIO Subsystem Configuration with Multiple Hosts 



Each base must include a base control card (BCC). The BCC controls 
access to the DLPs by multiple hosts and also provides base 
identification information to the hosts upon request. 



Bases that contain more than one distribution card must include a Path 
Selection Module (PSM), which handles priority resolution and routing of 
messages being returned to the hosts. 
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BASE IDENTIFICATION 



It is Important that each base be uniquely identifiable so that a base 
accessed through multiple paths can be recognized as a single base. A 
base's identification number is derived from its maintenance 
identification number because each base must already have a unique 
identification number for maintenance purposes and because it is 
desirable for a processor and its maintenance processor to display the 
same identification number when referring to the same base. 



Every B 5900 or B 6900 processor has an associated maintenance 
processor. The maintenance processor Is connected to a maintenance test 
bus, which allows maintenance routines to communicate with each base 
through a maintenance card (MC). Figure 12 represents a sample B 5900 
processor configuration, including the maintenance processor. 
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DC 
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Base control card MEC 

Card reader MLI 
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Disk Pack Drive Controller MT 
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Message-Level Interface 
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Magnetic tape 

Operator Display Terminal 

Train printer 



Figure 12. B 5<300 Processor and Maintenance Processor Configuration 



Every base must be connected to a maintenance test bus. Each 
maintenance test bus number must be unique within the entire system, and 
on a given maintenance test bus, each base address must be unique. 
Thus, each base can be uniquely identified by its maintenance test bus 
number and address. 
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In the configuration above, the maintenance test bus numbered 1 connects 
to two bases, which have been assigned the maintenance test bus 
addresses 1 and 2. This is shown by the notations "1/1," indicating 
"address 1/bus 1," and "2/1," indicating "address 2/bus 1." Note that 
the maintenance processor is shown connected to an Operator Display 
Terminal-DLP (ODT-DLP)., This connection is required only if the 
maintenance processor's display terminal is also to function as an ODT. 
The maintenance processor configuration for a B 6900 system is 
substantially different from this B 5900 processor configuration (see 
"B 6900 Maintenance Processor Configuration"). 



Each base includes a BCC, which will respond to a Test ID operation by 
returning a 16-bit, f ield-strappable base identification: 8 bits 
representing the maintenance test bus address of the base, 4 bits 
representing the maintenance bus number, and 4 bits that are currently 
unused and must be 0. 



See also 

B 6900 Maintenance Processor Configuration 85 



78 

PHYSICAL I/O OVERVIEW 
DLP AND UKIT IDENTIFICATION 

The DLP ID is a 16-bit number with two components: 

1. An 8-bit, f ield-strappable base unit number 

2. An 8-bit DLP type identification 



The DLP type identification specifies the type of the DLP (for example, 
a Magnetic Tape DLP (MT-DLP) or Card Reader DLP (CR-DLP)). The base 
unit number identifies the units connected to that DLP. Physical unit 
numbers are generated by assigning to the first unit on the DLP a unit 
number equal to the base unit number. Each subsequent unit (or 
potential unit) is assigned the next higher number, as shown in Figure 
13 of an MT-DLP. 



I MT-DLP — MEC- 
I 48 I 

I I 



MT Unit 48 
MT Unit 49 

MT Unit 51 



MT Unit 54 



- MT Unit 59 



- MT Unit 63 



MEG 

MT Unit 

MT-DLP 



= Master Electronic Control 

= Magnetic tape unit 

- Magnetic Tape Data Link Processor 



Figure 13. Physical Unit Numbers Assigned According to Base Unit Number 



There must be a one-to-one correspondence between units and unit 
numbers; that is, multiple units cannot be assigned the same unit 
number, and multiple unit numbers cannot be assigned to the same unit., 
These rules imply the following restrictions on the assignment of DLP 
base unit numbers: 
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1. Base unit numbers for DLPs that connect to different units must 
be unique. 

2. Base unit numbers must be assigned such that there is no 
possibility for the range of potential unit numbers to overlap. 
For example, in a configuration that included the MT-DLP shown 
in Figure 13, a DLP could not be assigned a base unit number of 
62, because the range of possible unit numbers for units 
connected to MT-DLP 48 includes unit 62. 

3. The range of unit numbers that must be considered "occupied" 
for a given DLP depends on the type of DLP. 

4. All DLPs that connect to the same units through an exchange 
must have the same base unit number, so that the unit numbers 
generated for the units will be the same through all paths. 



The unit number is not allowed to be assigned. 
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Table 6 shows the types of DLPs currently supported and the number 
potential units that can be configured behind DLPs of each type. 



of 



Table 6. Supported DLPs and Maximum Units per DLP 



DLP 


Peripheral 


No. of Units 


CR-DLP 


B9115/6/7 Card Reader 


1 


TP-DLP 


400-/750-/1100-/1500-lpra Train Printer 


1 


TP2-DLP 


B9246-X Model Printers 


1 


TP3-DLP 


B924 Model Drum Printer 


1 


PT-DLP 


B9246-X/B924 Model Printers 


1 




B9498 Streamer Tape 


4 


MT-DLP 


PE Tape 


16 


NRZ-DLP 


9-Traclc NRZ Magnetic Tape 


16 


GCR-DLP 


GCR Magnetic Tape 


16 


CP-DLP 


Card Punch 


1 


5NDF-DLP 


5N Disk, file 


16 


HT-DLP 


(Host Transfer) 
225/235/206/207/659/677 Disk. Pack. 


16 


ODT-DLP 


Operator Display Terminal 


3 


LSP-DLP 


Datacomm lines 


1* 


NSP-DLP 


Datacomm network (LSPs) 


1* 



* Defined to be 1 for this purpose. LSPs 
datacomm lines are selected by other means. 



and individual 



CP = Card Punch NSP 

CR = Card Reader NRZ 

DLP = Data Link Processor ODT 

GCR = Group Coded Recording PE 

HT = Host Transfer PT 

1pm = Lines per minute TP 

LSP = Line Support Processor 5NDF 
MT = Magnetic tape 



Network. Support Processor 

NonReturn to Zero 

Operator Display Terminal 

Phase-Encoding 

Printer tape 

Train printer 

5N disk file 
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PATH SPECIFICATION 



When requesting that an I/O be performed, PHYSICALIO selects a 
particular path by including the following information in the lOCB for 
the I/O: 

1. The ML IP number 

2. The MLI port number 

3. The Line Expansion Module (LEM) port number (described below) 

4. The DLP address (described below) 

5. The relative unit number of the unit (that is, the DLP-relative 
offset of the unit) 



A unique base is identified by the combination of MLIP number, MLI port 
number, and LEM port number. An LEM provides the capability to expand 
one MLI into several, allowing multiple bases to connect to one MLI 
port. 



The DLP address is a number that identifies the DLP within the selected 
base. The DLP address is also used by the PSM to resolve conflicts when 
multiple DLPs are ready to transmit data at the same time; DLPs with 
higher addresses have higher priority. 



For A 3, A 9, B 5900, and B 6900 systems. Table 7 indicates the 
valid values for selection numbers. 
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Table 7. Valid Selection Numbers to Identify I/O Path 
for A 3, A 9, B 5900, and B 6900 Systems 



i 


B 5900 


B 6900 


A 3 


A 9 


! MLIP Number * 


1-4 


1-4 


1-7 


1-7 


1 MLI Port Number 


0-3 


0-7 


0-2 


0-7 


1 LEM Port Number ** 


0-7 


0-7 


0-7 


0-7 


1 DLP Address 


0-7 


0-7 


0-7 


0-7 


1 Relative Unit Number *** 


0-15 


0-15 


0-15 


0-15 



* Matches the processor ID. 
** A LEM can have either 4 or 7 ports; the port numbers 

are in the range through 7. 
'** Depends on DLP type; 15 is maximum for any DLP. 



For A 3K and A 10 systems, Table 8 indicates the current valid values 
for selection numbers. 



Table 8. Valid Selection Numbers to Identify 
I/O Path for A 3K and A 10 Systems 



j 

1 


A 3K 


A 10 


1 

! MLIP Number 


1-7 


1-7 


1 MLI Port Number 


0-2 


0-7 


1 LEM Port Number * 


0-7 


0-7 


! DLP Address 


0-7 


0-7 


I Relative Unit Number ** 


0-15 


0-15 



A LEM can have either 4 or 7 ports; 

the port numbers are in the range through 7. 

Depends on DLP type; 15 is maximum for any DLP. 
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Figure 14 shows a disk unit reached by the path specified by MLIP 1, MLI 
port 0, LEK port 3, DLP address 2, relative unit 3. The disk, unit is 
identified with [*] at the end of the figure. 
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BCC = Base control card LEM 

CR = Card reader MC 

DC = Distribution card MLI 

DLP = Data Link. Processor MLIP 
DPDC = Disk Pack Drive Controller 

HT = Host Transfer TP 



= Line Expansion Module 
= Maintenance card 
= Message-Level Interface 
= Message-Level Interface 

Processor 
= Train printer 



Figure 14. I/O Path from Processor to Disk Unit 
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In addition to the path specifications described above, the lOCE 
contains the processor ID of the processor that initiated the I/O. For 
A 3. A 9, B 5900, and B 6900 systems, when an lOCB is unlinked from a 
result queue by PHYSICALIO, this processor ID is used to determine which 
processor is to finish processing the I/O. For A 3K and A 10 systems, 
any processor can flnl:3h processing any I/O. 



See al-so 

Processing of I/Os . 21 
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B 6900 MAINTENANCE PROCESSOR CONFIGURATION 



A sample B 5900 processor configuration including a maintenance 
processor was illustrated in Figure 12. Although the maintenance test 
bus connects to the bases in the same manner on the B 6900 system as it 
does on the B 5900 system, the B 6900 maintenance processor requires 
access to some peripherals that are not required by the B 5900 
maintenance processor, necessitating some additional configuration 
restrictions for the B 6900 system. 



Because the B 6900 maintenance processor does not Include a terminal for 
interacting with the system operator, the maintenance processor must 
have access to an ODT through an ODT-DLP. In addition, the maintenance 
processor requires access to a magnetic tape unit through an MT-DLP to 
load various programs and data (this information is accessed from a 
diskette on the B 5900 system). These DLPs must be located in the same 
base; this base is referred to as the "maintenance base" and is shown in 
Figure 15. 



PHYSICAL I/O OVERVIEW 
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BCC = Base control card MC 

DC = Distribution card MLI 

DLP = Data Link Processor ODT 

DPDC - Disk Pack, Drive Controller PSM 

HT = Host Transfer TP 



Maintenance card 
Message-Level Interface 
Operator Display Terminal 
Path Selection Module 
Train printer 



Figure 15. B 6900 Processor and Maintenance Processor Configuration 



Because all B 6900 maintenance processors generate a Host Return field 
of 0, a base can be the maintenance base for only one maintenance 
processor (because there can be only one distribution card 0). The 
maintenance test bus that connects to a maintenance base must originate 
in the maintenance processor associated with that base. 



The maintenance base must be visible to (that is, shared with) only that 
processor associated with the maintenance processor. To simplify the 
path specification, there must not be a LEM on the MLI between the 
maintenance processor and its maintenance base. 



87 



10 SYSTEM INITIALIZATION 



For the Master Control Program (MCP) on a Universal I/O (UIO) subsystem 
to begin system initialization, there must be valid bootstrap code. On 
A3, A 9, B 5900, and B 6900 systems, this bootstrap code is resident in 
the low addresses of memory. On A 3K and A 10 systems, the bootstrap 
code is loaded into memory from disk by the maintenance processor. The 
steps of the system initialization process, described below, begin at 
bootstrap code initialization. 

1. The bootstrap code can begin executing because of a Halt/Load, 
a Change MCP (CM), a fatal tape dump, a reconfiguration 
command, or some other software cause. The bootstrap's main 
task, is to initiate the GETITGOING procedure. The bootstrap 
has sufficient path information to perform I/Os to the 
Halt/Load unit, from which it reads the code for GETITGOING. 

2. GETITGOING reads in the necessary MCP data structures and 
"save" code. It also reads in and invokes all of the 
initialization procedures that select alternative modules based 
on the type of machine. These modules include PHYSICALIO 
(whose initialization procedure selects the PHYSICALIOHDP 
alternative for UIO subsystems), datacomm, maintenance, 
configuration control, and processor control. GETITGOING then 
calls PRIMARYINITIALIZE. 

3. PRIMARYINITIALIZE builds a more permanent stack for the MCP and 
moves to it, entering SECONDARYINITIALIZE in the process. 

4. SECONDARYINITIALIZE is the first procedure that recognizes the 
potential existence of other tightly-coupled processors. If 
there are multiple processors, one processor determines that it 
is the "leader" in the initialization process and coordinates 
the initialization of the other processors. The substeps of 
SECONDARYINITIALIZE describe the single-processor system; the 
multiple-processor system follows the same basic pattern, with 
the added complication of having to synchronize the leader and 
follower processors. 

After establishing its processor and memory environment, 
SECONDARYINITIALIZE calls PERIPHERALINITIALIZE. 

a. PERIPHERALINITIALIZE allocates space for I/O tables such 
as UNIT, UNITCONTROL, UNITMAP, and UNITSTATUS. It then 
calls PERIPHERALCONFIGURATOR with a parameter indicating 
that this call is from PERIPHERALINITIALIZE 
(PERIPHERALCONFIGURATOR is called at other times, such as 
when adding an outboard base and when freeing or acquiring 
a Data Link Processor (DLP)). PERIPHERALCONFIGURATOR then 
calls CONFIGPERIPHERALINITIALIZE. 



PHYSICAL I/O OVERVIEW 

b. The main task of CONFIGPERIPHERALINITIALIZE is to loop 
through all possible Message-Level Interface (MLI) ports 
and Line Expansion Module (LEM) ports, issuing a TEST UNIT 
operation to each potential base (see the "UIO Subsystem" 
section for configuration requirements). When a base is 
found, CDNFIGPERIPHERALINITIALIZE calls ADDABASE. 

c. ADDABASE performs a TEST ID operation on each potential 
DLP in the base, storing all of the resulting information 
in a bass entry template that is to be merged into th€' 
configuration table. ADDABASE then calls MERGEBASEENTRY . 

d. MEIRGEBAS GENTRY determines whether or not there is already 
information in the configuration table about this bas€' 
(for example, whether another processor has found it first 
or whether the base is described in the soft configuration 
file). If so, the base and DLP information derived by 
ADDABASE is merged in with the existing information (which 
may result in errors if the overlapping information is 
incompatible). If the base has not been seen before, a 
new base entry is added to the configuration table and 
ADDANENT:syTOOTHERTABLES is called once for each DLP in the 
base. 

e. ADDANENTRYTOOTHERTABLES determines whether this DLP 
connects to units that have already been seen through 
another path or whether this DLP connects to new units. 
If the units have already been seen, ADDAPATH is called to 
add the current path to the existing list of paths under 
the "pa:h node" for those units. If the DLP connects to 
new units, a new path node is entered in the path table, 
the current path is added to the path list, and each 
potential unit behind the DLP is assigned a physical and 
logical unit number and is added to the various physical 
and logical unit tables. If the units are of a type that 
cannot be configured behind a peripheral exchange (that 
is, if the units are "nonexchangeable" ) and if the units 
are of a type that requires peripheral status monitoring, 
STARTUNIT is called to start peripheral status monitoring 
for the units (see the "Peripheral Status" section). 

After per:: PHERAL INITIALIZE has been completed, 
SECONDARYINIT::aLIZE initiates the independent runners 
(including ETERNALIR and STARTSYSTEM) . finishes the remainder 
of its processor synchronization code, and begins normal 
process switching. 

STARTSYSTEM is left to finish the high-level initialization of 
the system. Including setting up the information required for 
managing disk files. STARTSYSTEM calls ACQUIREUNITS to verify 
that there are no unit-ownership conflicts among 
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loosely-coupled systems; if a conflict is detected, the 
initializing system will free the unit. In addition, 
ACQUIREUNITS attempts to acquire any exchangeable units that 
may belong to this group in a loosely-coupled environment. 
Once these units (if any) have been acquired, STARTSYSTEM calls 
PERIPHERALCONFIGURATOR (through SETUNITINFO) with a parameter 
indicating that peripheral status monitoring is to be initiated 
for all exchangeable units (see the "Peripheral Status" 
section) . 



See also 

Peripheral Status 91 

UIO Subsystem 73 
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11 PERIPHERAL STATUS 

Monitoring a unit's peripheral ready/not-ready status is performed by 
issuing special TEST operations to each unit. There are four types of 
TEST operations involved: 

1. TEST UNIT 

2. TEST/WAIT FOR READY 

3. TEST/WAIT FOR NOT READY 

4. TEST/WAIT FOR TRANSMIT (valid only for Operator Display 
Terminals (ODTs)) 



A TEST UNIT operation will finish "immediately" (that is, without 
vraiting), returning identification and status information for the unit 
to which it was directed. In contrast, a TEST/WAIT operation to a unit 
will not finish until the unit's status matches the status specified 
(for example, becomes "ready," in the case of TEST/WAIT FOR READY); the 
I/O Finish interrupt for a TEST/WAIT operation notifies the system that 
the unit requires attention, as its status may have changed. 



Most types of devices are monitored by alternating TEST/WAIT FOR READY 
operations with TEST/WAIT FOR NOT READY operations. However, the 
peripheral status monitoring process must take into account a few device 
dependencies. First, peripheral status is not monitored for devices for 
which it is not meaningful, such as Network. Support Processors (NSPs) 
and Line Support Processors (LSPs). Second, ODTs are monitored with 
TEST/WAIT FOR TRANSMIT operations, instead of TEST/WAIT FOR READY and 
TEST/WAIT FOR NOT READY operations, because of the nature of the device. 



The maintenance of valid peripheral status information depends on the 
issuing of an Initial TEST/WAIT operation when the unit first becomes 
visible to PHYSICALIO. During system initialization, peripheral status 
monitoring is initiated for nonexchangeable devices by 
ADDANENTRYTOOTHERTABLES and, later, for exchangeable devices by 
STARTSYSTEM. When a unit is taken from PHYSICALIO' s control (through 
TAKEUNIT), monitoring of peripheral status is stopped; when the unit is 
returned, GIVEUNIT reinitiates peripheral status monitoring if requested 
by the appropriate parameter value. Other processes by which units may 
become visible, such as through the ODT commands ACQUIRE and UR- , also 
Include initiation of peripheral status monitoring. 



Once the first TEST/WAIT operation has been issued, the process is 
self-sustaining (a new TEST/WAIT operation being issued whenever the 
current one completes) until monitoring is canceled for some reason (for 
example, by the ODT commands UR and FREE). The following sequence of 
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events occurs whenever a TEST/WAIT operation has completed: 

1. IOFINISH68 or I0riNISH_ASI0 is called by HARDWAREINTERRUPT to 
handle the I/O Finish interrupt. When IOFINISH68 or 
IOFINISH_ASIO determines that the I/O that finished is a 
peripheral status monitoring operation, lOSTATUS is called. 

2. If the completed TEST operation is a TEST/WAIT FOR TRANSMIT 
operation, IOSTaTUS initiates KEYIN to handle the operator 
input and to initiate a new TEST/WAIT FOR TRANSMIT operation. 
If the TEST operation was a TEST/WAIT FOR READY or TEST/WAIT 
FOR NOT READY operation, lOSTATUS determines whether or not the 
device has actually changed logical or physical status; if so, 
lOSTATUS updates the UNITSTATUS table to reflect the new status 
of the device, queues a message for PHYSICALPERIPHERALSTATUS 
indicating that the unit's status has changed, and initiates a 
new TEST/WAIT operation to wait for the opposite status 
condition. 



Note 

If an exception occurs, such as a 
TEST/WAIT FOR READY operation finishing 
with a NOT READY peripheral status, the 
unit is narked logically NOT READY and 
peripheral status monitoring for that 
unit cease:;. 



PHYSICALPERIPHERALSTATUS is called by ETERNALIR either when the MCP 
requests that it be called due to a status change on a unit, or 
approximately once every second. In other words, 
PHYSICALPERIPHERALSTATUS is called either on demand or at regular 
Intervals. PHYSICALPERIPHERALSTATUS reads each message' in its queue, 
talcing one or more of the following actions as appropriate: 

1. If the message indicates that peripheral status monitoring is 
to start for a unit (for example, if GIVEUNIT queues such a 
message), DOSTATUSIO Is called to initiate a TEST/WAIT 
operation of the type specified in the message. 

2. If peripheral status monitoring is to stop for a unit (for 
example, if TAJCEUNIT queues such a message), DOSTATUSIO is 
called to cancel the current TEST/WAIT operation on the unit. 
Because the command queue for the unit is marked "Suspended" 
when a TEST/WAIT operation is initiated. DOSTATUSIO initiates a 
cancel or discon':inue operation with an lOCB with the Immediate 
field in the MLIP Control Word (Word 0) set to TRUE, causing 
the MLIP to initiate the cancel operation regardless of the 
fact that the command queue is suspended. When the TEST/WAIT 
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operation has been canceled, DOSTATUSIO initiates an MLIP 
Activate Queue command to reset the Suspended field for the 
command queue. 

If the message indicates that a peripheral's status has 
changed, LOGICALPERIPHERALSTATUS is called. 
LOGICALPERIPHERALSTATUS updates the status for the unit in the 
UNIT table and tak.es other action as appropriate based on the 
unit's type and its current status. For example, if a magnetic 
tape unit changes status from not ready to ready, READALABEL is 
initiated. 
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12 DATA COMMUNICATIONS 



Data communications operations are handled by three special-purpose Data 
Link, Processors (DLPs): the Network Support Processor (NSP), the Line 
Support Processor (LSP), and the Data Communications Data Link. Processor 
(DC-DLP). This section describes these DLPs and the functions provided 
by the DCCONTROL and PHYSICALIO modules of the Master Control Program 
(MCP) to support data communications. 



NSPs . LSPs. AND DC-DLPS 



NSPs and LSPs are programmable DLPs that provide data communications 
services. Both are programmed using the Network Definition Language II 
(NDLII). LSPs run the Adaptor Control portion of the NDLII code, and 
NSPs run the Editors and Line Control portions of the NDLII code. 



Each DLP also runs an Executive program. The NSP Executive maintains a 
dialog with an MCP process called DCCONTROL and with the LSPs it 
controls. The LSP Executive supports the dialog with the NSP. DC-DLPs 
are NSPs that have built-in LSPs. DC-DLPs are not programmable with 
NDLII and only run specific protocols. The MCP communicates with 
DC-DLPs in the same manner as do NSPs. 



For its configuration tables, PHYSICALIO considers NSPs, LSPs, and 
DC-DLPs to be single-unit DLPs. Message routing to a particular LSP, 
line, and station is performed by the NSPs, LSPs, and DC-DLPs 
themselves. Although all LSPs must be in bases that are visible to 
their controlling NSPs, they need not be in bases that are visible to 
the host. NSPs act as "outboard hosts," providing an indirect 
communication path between the LSPs and the host (see the "UIO 
Subsystem" section for a configuration diagram that includes NSPs and 
LSPs). Because LSPs may be "invisible" to the host during system 
initialization, PHYSICALIO must be able to add LSPs to its tables as 
datacomm is being initialized. 



See also 

UIO Subsystem 73 
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DATACOMM I/O REQUESTS 



A typical datacomiti I/O request from a user program follows a path 
schematically similar to the following: 

program -> DCCONTROL -> PHYSICALIO -> UIO subsystem 



The datacomm I/O request (for example, a read or a write) is passed to 
the MOP DCCONTROL process, which calls a PHYSICALIO interface procedure 
to initiate the actual I/O operation. From PHYSICALIO to the 
destination terminal, the I/O can follow the following paths: 

PHYSICALIO -> MLIP -> NSP -> LSP -> terminal 



I 



-> DC-DLP — > 



The I/O is passed to the Message-Level Interface Program (MLIP), which 
routes the request to the NSP. The NSP then sends a request through a 
Message-Level Interface (MLI) to the LSP that controls the line 
connected to the terminal. 



This transmission process involves many levels of communication. For 
example, at a basic level, the NSP communicates with the LSP over an 
MLI; at a higher level, the NSP communicates control information and 
data to the LSP through the messages transmitted over the MLI. 
Similarly. DCCONTROL initiates normal I/O operations through PHYSICALIO 
to the NSP; at a higher level, the data transferred by these I/O 
operations is used to maintain a request/response dialog between 
DCCONTROL and the NSP. 
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DATACOMM INITIALIZATION 



There are several conditions that will cause datacomm to be initialized, 
including the entering of certain Operator Display Terminal (ODT) 
commands and the setting of some system options. When datacomm is to be 
initialized for an NSP or DC-DLP, the MCP process DCC0NT20L is 
initiated. (There is a separate activation of DCCONTROL for each NSP; 
for simplicity, only a single activation Is described here.) DCCONTROL 
calls DCINITIAL to begin the initialization. DCINITIAL performs the 
following steps: 

1. DCINITIAL first calls procedures in the DATACOMSUPPORT library 
to build the datacomm tables. 



DCINITIAL then calls the PHYSICALIO 
to load the NSP firmware. 



procedure INITIALIZEDCLCP 



Once the NSP firmware has been loaded, ADDANOUTBOARDBASE is 
called; it performs TEST operations through the NSP to the base 
containing its LSPs so that the LSP base can be added to the 
configuration tables. 

Next, DCINITIAL allocates two Input/Output Control Blocks 
(lOCBs): one is used to transmit the NSP requests required to 
establish the network configuration and to load the NDLII code 
from the DATACOMINFO file, and the other is used to receive the 
NSP's acknowledgments of the requests. These I/Os are 
initiated through the PHYSICALIO interface procedure 
INITIATECHARIO. 



DCCONTROL then calls SCIOINITIALIZE to set up the 
normal operation. 



I/O structures for 



During normal operation, each NSP has three allocated command queues. 
One of these queues is for read operations. The other two queues are 
used for write operations, one for normal output and one for control. 
Each queue has an active limit of one. 



SCIOINITIALIZE allocates a large number of lOCBs and input buffers of 
various sizes for read operations; these lOCBs are then initiated, 
through INITIATECHARIO, into the input command queue. Additional lOCBs 
are allocated for output operations, but are not initiated until 
required. 
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Prior to beginning normal operation, DCCONTROL calls DCPCONTROLLES to 
process any spontaneous Input messages that were received during the 
initialization phase. 
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NO]gMAL DATACOMM OPERATION 



A typical request/response cycle requires two physical I/Os: a write to 
send the NSP request and a read to receive the NSP response. For 
example, to perform a write to a terminal, DCCONTROL would initiate an 
lOCB with the following information in the I/O buffer: 



NSP Request 
Information 
[for example, 
WRITE) 



Identification 
Tag 



NDLII Program 

Control 

Information 



Data for the 
Terminal 



When the NSP has received the request through the MLI , it sends a DLP 
result to the MLIP; the MLIP stores the result information, and 
FINISHOFFIO causes the event specified in the lOCB, which notifies 
DCCONTROL only that the NSP has received the request. The NSP then 
transfers the data for the terminal to the LSP in a message that also 
contains LSP control information. When the data has been written to the 
terminal, the LSP returns a result to the NSP. The NSP then formats a 
result message and sends it to the system. Multiple results can be 
transferred to the I/O buffer. The data returned includes the following 
information: 



NSP Result 
Information 



Identification I NDLII Program 
Tag I Result 

I Information 



When this I/O completes, 
associate the response 
DCPCONTROLLER to return 
program. 



DCCONTROL uses the identification tag to 
with its corresponding request and calls 
the result information to the requesting 



In steady-state operation, DCCONTROL uses the "POBOX" mechanism to wait 
for one of several conditions to happen. The POBOX mechanism allows a 
process to assign an identifying "signature" to each of an arbitrary 
number of events, called "MEMOs." The process then monitors its POBOX 
until one of two conditions occurs: a MEMO is received, indicating that 
the event associated with that MEMO has happened, or a specified timeout 
period elapses. MEMOs are queued, if necessary, and are returned to the 
process in chronological order of their happening. Based on the 
signature, the process takes the appropriate action for each MEMO. 
DCCONTROL assigns MEMOS for the following events: 
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Completion of a write operation 
Completion of a read operation 
Queuing of an I/O request from a program 
The DCCONTROL stack's EXCEPTIONEVENT 



When a write operation completes, DCCONTROL notes that the I/O was 
completed and deallocates the data buffer but takes little additional 
action until the read of the NSP result completes. 



When a read operation is complete, DCCONTROL examines each of the 
messages in the input buffer. If a message indicates that a requested 
operation is now complete, DCCONTROL calls DCPCONTROLLER to pass the 
result Information to the requesting program. At this point, DCCONTROL 
can initiate writes to the NSP for previously requested actions that 
were queued until the proper conditions existed. 



When an I/O request is queued, DCCONTROL interprets the request and 
initiates the appropriate l/0(s) or queues the request itself for later 
action. 



When DCCONTROL "s EXCEPTIONEVENT is caused, DCCONTROL analyzes its 
TASKVALUE to determine what action to take. If an NSP dump is 
requested, DCCONTROL calls the PHYSICALIO procedure DUMPDCDLP. If 
termination of datacomm was requested, DCCONTROL calls SCIOSHUTDOWN, (as 
described in "Datacomm Termination"), and then terminates. 



When no MEMOs are received, DCCONTROL unconditionally waits 
140 milliseconds and then processes any queued MEMOs. If there are no 
MEMOS queued, DCCONTROL waits ten seconds for a MEMO to be queued. If a 
MEMO is not queued in ten seconds, a null request message is sent. 
After the third consecutive null request message is sent with no MEMO 
received, DCCONTROL displays a message Indicating that the NSP is not 
responding. 



See also 

Datacomm Termination 101 
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DATACOMM TERMINATION 



Termination of a datacomm process can result from any one of several 
operator input messages. When DCCONTROL detects that it has been 
terminated, it calls SCIOSHUTDOWN. SCIOSHUTDOWN calls BLASTUNIT to 
cancel all outstanding I/Os and returns canceled results to the 
requesting program(s). DCCONTROL then calls DCTERMINATE, which gives 
PHYSICALIO control (through GIVEUNIT) of the NSP and its LSPs, returns 
program requests that were queued waiting for initiation, and 
deallocates all message areas. If the last DCCONTROL process is 
terminating, DCTERMINATE also deallocates all datacomm tables. 
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base 



A hardware unit In the Input/Output (I/O) subsystem that contains 
the components necessary for handling the routing of messages 
between the Data Link Processors (DLPs) and the host processor 
through the Message-Level Interface Processor (MLIP). The base 
itself contains at least one DLP. 



base control card (BCC) 

A base module that identifies a base and- controls access to its Data 
Link. Processors (DLPs) and to the base itself. 



BCC 



See "base control card." 



Card Reader Data Link. Processor (CR-DLP) 

A processor that serves as the controller of a card reader and 
provides the I/O interface between the system and the card reader. 



Change MCP (CM) 

An Operator Display Terminal (ODT) command that specifies a 
particular Master Control Program (MCP) code file on an optionally 
specified disk pack family as the MCP code file to be used at the 
next Halt/Load. 



CM 



See "Change MCP." 



Conimunlcate with Universal I/O (CUIO) 

An operator that passes the address of an I/O Control Block (lOCB) 
to the Message-Level Interface Processor (MLIP) for initiation. 
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CR-DLP 

See "Card Reader Dat;a Link. Processor." 

CUIO 

See "Communicate with Universal I/O." 



DATACOMINFO file 

A file that contains a complete description of the datacomm 
configuration, incZ.uding algorithms, editors, and translate tables. 
This is the file thcit the Interactive Datacomm Configurator (IDC) 
modifies and from which the Master Control Program (MCP) initializes 
the data communicat:.ons subsystem. 



Data Communications Data Link Processor (DC-DLP) 

A data communications processor that combines the functions of the 
Network Support Processor (NSP) and Line Support Processor (LSP) 
into one physical Data Link. Processor (DLP) and supports up to four 
lines of communicati.on. 



Data Link. Processor (DLP) 

A processor that serves as the controller of one or more peripheral 
devices or data communications lines and provides the interface 



between the system and the peripherals and lines. 



Data Link. Processor Address Word (DLPAW) 



Contains several fields used by the Message-Level 
Processor (MLIP) to address a Data Link. Processor (DLP). 



Interface 



DC 



See "distribution card. 
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DC-DLP 

See "Data Communications Data Link. Processor." 

Disk Pack. Drive Controller (DPDC) 

An interface between the Data Link Processor (DLP) and disk. pack, 
units. 

distribution card (DC) 

A base module that acts as an interface between a host and a base. 

DLP 

See "Data Link Processor." 

DLPAW 

See "Data Link Processor Address Word." 

DPDC 

See "Disk Pack Drive Controller." 

EMP 

See "E-Mode Processor." 



EMP Destination Set (EMPDS) 

Contains the destination set of E-Mode processors that are signaled 
when an I/O has finished. 



EMPDS 

See "EMP Destination Set (EMPDS)." 
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E-Mode Processor (EMP) 

The central processing unit in Burroughs E-Mode architecture. 



FIB 



See "File Informaticn Block.." 



File Information Block. (FIB) 

Contains information about the user I/O that is passed to the 
PHYSICALIO module. 



GCR-DLP 

See "Group Coded Recording Data LinK Processor." 

Group Coded Recording Data Link Processor (GCR-DLP) 

A processor that serves as the controller of a Group Coded Recording 
(GCR) magnetic tape drive and provides the I/O interface between the 
system and the GCR Magnetic tape drive. 

Halt/Load 

A process that starts or restarts the Master Control Program (MCP). 



HDU 



See "Host Data Unit, 



Host Data Unit (HDU) 

The B 7900 or A 15 system host interface to the Input/Output (I/O) 
subsystem. An HDU is configured with three host-dependent ports, 
each of which supports two Message-Level Interface (MLI) cables. A 
B 7900 or A 15 host processor can have more than one HDU. The 
B 7900 and A 15 systems are called "HDU machines." 
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Host Transfer Data Link Processor (HT-DLP) 

A processor that communicates information to the Disk. Pack Drive 
Controller (DPDC) that interfaces up to 16 disk drive units. 

HT-DLP 

See "Host Transfer Data Link Processor." 



Input/output (I/O) 

An operation in which the system reads data from or writes data to a 
peripheral device such as a disk drive. 



Input/Output Control Block (lOCB) 

A data structure used for communication between the host system and 
the Message-Level Interface Processor (MLIP). 



Input/Output Control Word (lOCW) 

Area in the lOCB where information about the I/O to be performed 
resides. 



lOCB 

See "Input/Output Control Block." 

lOCW 

See "Input/Output Control Word." 

I/O 

See "input/output." 
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LEM 

See "Line Expansion Module." 



Line Expansion Module (LEM) 

A hardware module that allows the attachment of several bases to 
single Message-Level Interface Processor (MLIP) port. 



Line Support Processor (LSP) 

On Message-Level Interface Processor (MLIP) systems, the data 
communications subsystem processor that manages communication with 
the host and initiates processes that control the input of messages 
to and output of mesisages from data communications lines. 



1pm 



Acronym for "lines per minute" used when describing the printing 
speed of a train printer. 



LSP 



See "Line Support Processor." 



Magnetic Tape Data Link Processor (MT-DLP) 

A processor that serves as the controller of a magnetic tape drive 
and provides the 1/0 interface between the system and the tape 
drive. 



Maintenance card (MC) 

A base module that acts as an interface between a maintenance test 
bus and a base. 



Master Control Progreum (MCP) 

The operating system on A Series and B 5000/B 6000/B 7000 Series 
systems: the progi.-am that controls the operational environment of 
the system,. This control Includes memory management, job selection, 
peripheral management, system utilization, program segmentation, 
subroutine linkage, and error logging. 
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Master Electronic Control (MEC) 

An Interface between the Magnetic Tape Data Link. Processor (MT-DLP) 
and the magnetic tape (MT) units that the MT-DLP supports. 

MC 

See "Maintenance card." 

MCP 

See "Master Control Program." 

MEC 

See "Master Electronic Control." 



Message-Level Interface (MLI) 

The interface between the host system and the Input/output (I/O) and 
data communications subsystems. 



Message-Level Interface Processor (MLIP) 

The input/output (I/O) processor associated with a central processor 

unit. 



Message-Level Interface Processor Destination Set (MLIPDS) 

Contains the destination set of MLIPs that can be signaled for I/O 
initiation. 



MLI 

See "Message-Level Interface." 
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MLIP 

See "Message-Level Interface Processor." 

MLIPDS 

See "Message-Level Interface Processor Destination Set." 

MT-DLP 

See "Magnetic Tape Data Link, Processor." 

KDLII 

See "Network. Definition Language II." 

Network Definition Lang,iiage II (NDLII) 

The Burroughis language used to describe the physical, logical, and 
functional characteristics of the data communications subsystem on 
Message-Level Interface Processor (MLIP)/Host Data Unit (HDU) 
systems. 



Network Support Processor (NSP) 

On Message-Level Interface Processor (MLIP) systems, the data 
communications subsystem processor that controls the MLIP. 



New Programming (NEW?) language 

A structured, high-level programming language used in developing 
some of Burroughs system software. 



NEWP 

See "New Programming (NEWP) language." 
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NonReturn to Zero Data Link. Processor (NRZ-DLP) 

A processor that serves as the controller of a NonReturn to Zero 
(NRZ) tape drive and provides the I/O Interface between the system 
and the NRZ tape drive. 

NRZ-DLP 

See "NonReturn to Zero Data Link Processor." 

NSP 

See "Network Support Processor." 

ODT 

See "Operator Display Terminal." 

ODT-DLP 

See "Operator Display Terminal Data Link. Processor." 



Op<?rator Display Terminal (ODT) 

The system console device that allows the operator to enter commands 
directly to the operating system to perform various functions. 



Optjrator Display Terminal Data Link. Processor (ODT-DLP) 

A processor that serves as the controller of an Operator Display 

Terminal and provides the I/O interface between the system and the 
Operator Display Terminal. 



Path Select Module (PSM) 

The state of the CANDE input queue after the original executing 
command has finished. At that time, a CANDE "?G0", "7WAIT", 
"7PURGE", "7TAKE", or "7ENTER" command can be entered to manipulate 
the queue, or the queued input can be discarded by entering any 
other CANDE command. 
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PE-DLP 

See "Phase-Encoding Data Link Processor." 

Phase-Encoding Data Link Processor (PE-DLP) 

A processor that serves as the controller of a Phase-Encoding (PE) 
tape drive and provides the I/O interface between the system and the 
PE tape drive. 

PSM 

See "Path Select Module." 

Signal Processing Elemem: Set (SPES) operator 

An operator that signals an MLIP for I/O initiation. 

SPES operator 

See "Signal Processing Element Set (SPES) operator." 

TP-DLP 

See "Train Printer Data Link. Processor." 

Train Printer Data Link Processor (TR-DLP) 

A processor that ser^7es as the controller of a train printer and 
provides the I/O interface between the system and the printer. 

UIO 

See "Universal Input/Output." 

unit 

A peripheral device jsuch as a disk drive. 
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Unit Reserved (UR) 

An Operator Display Terminal (ODT) command used to reserve a unit 
identified by a device name and unit number. The "-" option 
restores the unit identified by the device name and unit number. 



Universal Input/Output 

The input/output (I/O) subsystem that manages all transfers of 
information between the operating system and peripheral devices. 



UR 

See "Unit Reserve (UR)." 

UR- 

See "Unit Reserve (UR)." 

WATI operator 

WATI is a mnemonic for "read machine identification." The WATI 
operator Identifies the system in use and determines which I/O 
method is to be used. 
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Base control card (BCC), 74 
BUILDIOCB, 16 
BUILDLOGICALRD, 26 



Command queue, 30, 42 
Head lOCB Link, 43 
Horizontal Queue Head Pointer, 43 
Horizontal Queue Link, 43 
Queue Control Word, 42 
Active Count, 42 
Active Limit, 42 
Command Queue Header Mark, 42 
Horizontal Queue Present, 43 
Inactive Count, 42 
Suspended, 42 
Waiting, 43 
Tail lOCB Link, 43 
Communicate with Universal I/O, See CUIO operator 
Configuration table, 88 
CUIO operator, 30, 39 



Data communications operations, 95 

datacomm I/O requests, 96 

datacomm initialization, 97 

datacomm termination, 101 

DLP types 

Data Communications Data Link Processors (DC-DLP), 95 
Line Support Processor (LSP), 95 
Network Support Processor (NSP), 95 

normal datacomm operation, 99 
Data Link Processor, See DLP 
Data structures 

command queue, 42 

for A 3, A 9, B 5900, and B 6900 systems, 30 

for A 3K and A 10 systems, 31 

horizontal queue, 58 

lOCB, 15 

lOCB I/O table, 33 

lOCB queue, 41 

MLIP I/O table, 56 

result queue, 60 

shared, 29 

unit queue, 48 
Datacomm, See Data communications operations 
DCCONTROL, 95 

Descriptor link. See MLIP/UIO interface 
Disk seek optimization, 32 
Distribution card (DC), 73 
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DLP 

address, 81 

card reader, 10 

host transfer, 10 

train printer, 10 

types, 95, See also Data communications operations 
DO procedures, 17 



EMP destination set, 31 
Exception handling, 26 



Horizontal queue, 58 
Host return field, 71, 73 



I/O 

exception handling, 26 
Finish interrupt, b?. 
mask., 26 
processing, example;; of 

for A 3, A 9, B 15900, and B 6900 systems, 22 
for A 3K and A 10 systems, 23 
Identification number 
base, 75 
maintenance, 75 
Initialization, system, See System initialization procedures 
INITIATE procedures, 17 
Input/Output Control Block., See lOCB 
Invalid Operand interrupt, 39 
lOCB, 15, 33 

Command or Unit Queue Header Pointer, 37 
DLP Address Word, 37 
DLP Command/Result Lengths, 37 
DLP I/O Command Pointer, 37 
DLP I/O Result Pointer, 37 
I/O Finish Time, 39 
I/O Start Time, 39 
MLIP Control Word, 34 
Attention, 34 

Cause I/O Finish Interrupt, 34 
Continue Count at End of Length, 35 
Disk Seek Optimization, 36 
Don't Count, 36 
Ignore Count Error, 36 
Ignore Suspend A].l Queues, 36 
Immediate, 36 
Input, 35 
lOCB Mark, 34 
Memory Direction, 35 
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lOCB (cont. ) 

Memory Override, 35 
MLIP/DLP Command, 34 
Output, 35 
Output Zeros, 35 
Queue at Head, 34 
Simple Path Selection, 36 
Tag Control, 35 
Word-Oriented Transfer, 35 
MLIP Current Data Area Pointer, 38 
MLIP Current I/O Length, 38 
MLIP State and Result, 38 
Attention, 38 

Completed After Queue Suspended, 39 
DLP Error, 38 
Exception, 38 
MLIP Not Available, 39 
MLIP/Hardware Error, 39 
MLIP/MLI Error, 38 
Next lOCB Link:, 37 
Result Mask., 37 
Result Queue Head Pointer, 37 
Self Pointer, 37 
lOCB I/O table, 33 
IOCS interface procedures, 15 
lOCB queue, 41 
lOCB Queue 

Control Word, 41 
Head, 41 
Tail, 41 
lOERROR, 26 
lOEXCEPTION, 26 



Line Expansion Module (LEM) port number, 81 



Maintenance card, 75 
Maintenance test bus, 75 
MCP I/O requestor 
main sets 

Kernel, 12 
Maintenance, 12 
MCP, 12 
User, 12 
types of modules, 11 
MEMO. 99 

Message-Level Interface Processor, See MLIP 
MLIP, 65 
commands 

Activate Queue, 66 
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MLIP (cont. ) 

Clear DLP Status, 6 7 

Deactivate Queue, eb 

Decrement Unit Active Limit, 69 

Discontinue Error lOCB, 66 

General Clear, 68 

Increment Unit Active Limit, 69 

Read DLP Status, 67 

Read MLIP Status, tl 

Reset the Suspend All Queues Flag, 66 

Return Active lOCB, 68 

Return Queue, 67 

Set I/O Table EMPD£; , 68 

Set I/O Table MLIPDS, 68 

Set the Suspend All Queues Flag, 66 

Set Unit Queue I/O Optimization Word 2, 69 

Set Unit Queue Path Word, 68 

Wait for Error, 65 
destination set, 31 
error handling, 63 
I/O subsystem, 1 
I/O subsystem overview, 7 
systems, 1 
KLIP I/O table, 56 

EMP Destination Set, 57 
lOCB Queue Head Pointer, 56 
MLIP Destination Set, 57 
MLIP I/O Table Control Word, 56 
MLIP Queue Control Word, 56 

Lock. Bit, 57 

MLIP Queue Mark, 57 
MLIP Queue Head Unit Queue Link. Data Descriptor, 57 
MLIP Queue Tail Unit Queue Link Data Descriptor. 57 
MLIP Scratch Area Word through Word 9, 57 
MLIP Suspend All Queues field, 36 
MLIP/UIO interface, 71 
descriptor link, 71 



Network Definition Language II (NDLII), 95 



Path Selection Module (PSM), 74 
Peripheral status, test operations for 

TEST UNIT, 91 

TEST/WAIT FOR NOT READY, 91 

TEST/WAIT FOR READY, 91 

TEST/WAIT FOR T;RANSMIT, 91 
Physical I/O 

major components of, 7 

standard path for, 7 
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PHYSICALIO module, 11, 21 
PHYSICALIO/MLIP interface, 29, 33 
PHYSICALIO/MLIP mechanisms 

A 3, A 9, B 5900, and B 6900 systems. 29 

A 3K and A 10 systems, 31 



Requestor/PHYSICALIO interface, 15 
Requestors, MCP, See MCP I/O requestor 
Result queue, 60 



Signal Processing Element Set (SPES) operator, 29 

SPES operator. See Signal Processing Element Set (SPES) operator 

System initialization procedures, 87 

ACQUIREUNITS, 88 

ADDABASE, 88 

ADDANENTRYTOOTHERTABLES , 88 

CONFIGPERIPHERALINITIALIZE, 87 

GETITGOING, 87 

MERGEBASEENTRY , 88 

PERIPHERALCONFIGURATOR, 87 

PERIPHERALINITIALIZE, 87 

PRIMARYINITIALIZE, 87 

SECONDARYINITIALIZE, 87 

STARTSYSTEM, 88 



UIO 

bases, 9 

hardware configuration, 9 

overview, 9 
UIO bases, 9 
UIO subsystem, 73 
UIO subsystem configuration 

configuring B 6900 maintenance processor, 85 

identifying base, 75 

identifying DLP and unit, 78 

identifying host, 73 

specifying paths, 81 
Unit information modules 

FILEFINDER, 14 

MCPSTATUS, 14 

UNITID, 14 
Unit information tables 

UNITCONTROL, 28 

UNITMAP, 28 

UNITSTATUS, 28 
Unit interface procedures 

GETLOGICALUNITSTATUS, 20 

GETUNITINFO, 20 
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Unit interface procedures (cont.) 
GIVEUNIT, 19 
SETUNITINFO, 20 
TAKEUNIT, 19 
Unit number 
logical, 19 
physical, 19 
Unit queue, 48 

Dynamic Unit Queue Link,, 50 
Head lOCB Link., 50 
Horizontal Queue Head Pointer, 50 
I/O Optimization Word 1, 50 

Bypass Count, 51 

Bypass Limit, 51 

Disk Address, 51 

Maximum lOCBs to Examine, 50 

Physical Integrity Check., 50 
I/O Optimization Word 2, 51 

Cylinder Size, 51 

Minimum Difference, 51 
Last lOCB Initiated, 50 
Path Table Pointer, 51 
Queue Control Word, 48 

Active Count, 48 

Active Limit, 49 

Connection in Progress, 49 

Horizontal Queue Present, 49 

Inactive Count, 43 

Lock Bit, 50 

Path Selected, 49 

Suspended, 49 

Unit Queue Header Mark, 48 

Waiting, 49 

Waiting in MLIP Qaeue, 50 
Spare, 50 

Tail lOCB Link, 50 
Unit-Related Path Information, 51 

unit DLP Mask, 51 
Unit queue header, 48 
Universal Input/Output, See UIO 



WATI operator, 21 



